Assigning to me.

_Actually_ assign to me.

Please try updating to the latest packages (3.0.1_fc-9,
gcc4-4.0.0-0.22, libgcj4-4.0.0-0.22) and see if this happens again. 
One thing to note is that you must have your java alternative set to
java-1.4.2-gcj4-compat like so:

su - -c "update-alternatives --set java \
  /usr/lib/jvm/jre-1.4.2-gcj4/bin/java"
su - -c "update-alternatives --set javac \
  /usr/lib/jvm/java-1.4.2-gcj4/bin/javac"

Any news here?

Sorry, been busy so haven't had time to track rawhide that closely lately.

Just tried again, made sure the gcj4 alternatives were set for java and javac,
and still get the same error.

Now installed:
eclipse-platform-3.0.1_fc-14
eclipse-jdt-3.0.1_fc-14
eclipse-ecj-3.0.1_fc-14
eclipse-gtk2-3.0.1_fc-14
eclipse-source-3.0.1_fc-14
eclipse-pde-3.0.1_fc-14
package ecj is not installed

libgcj4-4.0.0-0.22
libgcj4-devel-4.0.0-0.22
java-1.4.2-gcj4-compat-1.4.2.0-3jpp
java-1.4.2-gcj4-compat-devel-1.4.2.0-3jpp

(Also all the gcc 3 gcj stuff, which I assume is not apropos)

When I originally did the test, I had the Sun JDK 1.5.0, built into rpms from
the jpackage specfile, installed and set as the alternative for all java stuff.
 Now I've updated to jre 1.5.0_01, just used the sun rpm this time (couldn't get
the jpackage spec working on it in the little time I spent), and the behavior is
slightly different; with it set to be the alternative for java, I still get no
response to clicking "workbench basics", but now I don't get the error message
on the console either.  But when I run it with the gcj4 alternatives, I do get
the error message.

Now, I know this all may not be very useful to you, could be because of duelling
java installs or something.  But what bothers me about this is, doesn't Eclipse
normally run fine under the Sun JVM?  And if this build of Eclipse is compiled
like I've heard, why is there the dependency on having the java alternative set?
 Clearly I'm not in possession of the full picture here.

(BTW I'm running the Sun JVM for Azureus.  Which uses SWT too, but chokes so bad
on gcj that it wipes out my config file every time I try it.)

I can't duplicate this with our new 3.1 M5a builds.  Does it still
happen for you?

The builds of Eclipse we're shipping have both the bytecode and the
corresponding shared objects.  When your java alternative is set to
java-1.4.2-gcj-compat, /usr/bin/java calls gij which interprets the
options in /usr/bin/eclipse to load shared objects instead of
interpreting the bytecode.  This allows us to natively-compile Eclipse
without heavy modifications to Eclipse itself.  The other advantage is
that switching your java alternative to a proprietary JVM should Just
Work with the bytecode that's also shipped.

As for Azureus, I should start testing that - it's popular enough that
it'd be a good showcase app for the free java stuff.

Ok, running today's rawhide, and with a clean install of the java
stuff (as in I blew out *everything* remotely java, to the point of
the java/javac alternatives being gone, then reinstalled), the eclipse
problem is now gone.

I haven't reinstalled Sun JVM to see if it works with that too yet,
but that's somewhat irrelevant from the Fedora POV so I'm closing this
bug now.

Looks like regression in current rawhide. Eclipse currently crashes during
startup, generating the following errors:

with 3.1.0_fc-0.M6.9: http://phy.duke.edu/~icon/misc/eclipse-error.log
with 3.1.0_fc-0.M6.10: http://phy.duke.edu/~icon/misc/eclipse-error-2.log

I can reproduce this on 3 different machines both with pre-existing and
clean-slate environment setups.

I think it has something to do with this bug:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145240

Re-opening.

It looks like the original issue has been fixed.  The startup issues are
actually due to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155693 . 
Konstantin, please file any more issues you find (with tomorrow's xml-commons)
there.  Thanks.

Closing.

Yes indeed, it works great! Thanks for your help.