From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4 Description of problem: The compiled version of Eclipse shipped with Fedora Core 4 has several problems. Some that I did not read on bugzilla are: 1) It is impossible to edit or remove entries in the User Library Editor (exceptions are generated--I'm including my .log). 2) Undo/Redo is permanently ghosted (and not working). 3) "Organize imports" doesn't do anything. I'm part of the JPackage group and I've been always absolutely happy with the JPackage-packaged Eclipse. Now Fedora is using the same package names, so it will be VERY difficult to avoid the automatic "upgrade" to the compiled version. I think the users should have a choice: I use Eclipse several hours a day and now I'm scared. Version-Release number of selected component (if applicable): 3.1M6 How reproducible: Always Steps to Reproduce: 1. Start Eclipse 2. Open Window/Preferences/Java/Build Path/User Libraries 3. Try to edit or remove a jar from a library Additional info:
Created attachment 115524 [details] Eclipse log
I can't say that I've experienced any of the problems you're reporting. Try rm -rf ~/.eclipse and a new workspace. There is also the chance that some of this is are upstream issues that were in M6. We have M7 in rawhide (yum --enablerepo=development install eclipse-jdt) and when 3.1 final comes out I'll be pushing it as an update. Okay, now looking at your stack trace it appears that you're not using our natively-compiled stuff but are using the Sun JVM. While not explicitly "supported", this _should_ work. Try rm -rf ~/.eclipse and a new workspace and let me know what happens. You could also try switching your alternatives (java and javac) to java-gcj-compat to see if these problems exist with the setup we're shipping.
A new *workspace*? Sorry, can't afford that. I'll wait patiently, hoping in the updates.
BTW, in which sense I'm not using the natively compiled stuff? I just started eclipse after updating, and got the "Native Eclipse" splash screen. Is there any hidden setting that should be tuned?
(In reply to comment #3) > A new *workspace*? Sorry, can't afford that. I'll wait patiently, hoping in the > updates. eclipse -data <new workspace location>
(In reply to comment #4) > BTW, in which sense I'm not using the natively compiled stuff? Your log showed Sun references. > I just started > eclipse after updating, and got the "Native Eclipse" splash screen. Is there any > hidden setting that should be tuned? java -version; javac -version # update-alternatives --display java; update-alternatives --display javac What are your java and javac alternatives set to?
OK, more data. Deleting .eclipse and using a new workspace made no difference. I was using java 1.5.0_03. I used alternatives to set /usr/lib/jvm/jre-1.4.2-gcj/bin/java as the default JVM, and eclipse hangs on startup in a busy loop. I'll do more testing and report. My problem here is that you are substituting a perfectly working eclipse package with a problematic package with the same name. The new package frees me from being able to use the JVM I want (I used previously eclipse with BEA and Sun JVMs without problems) and hurts me in one of the tools I use most of the day.
(In reply to comment #7) > Deleting .eclipse and using a new workspace made no difference. That's really bizarre. > I used alternatives to set /usr/lib/jvm/jre-1.4.2-gcj/bin/java as the default > JVM, and eclipse hangs on startup in a busy loop. > > I'll do more testing and report. Okay, I would appreciate it. I've yet to see this kind of behaviour. Try it with a new workspace just to be sure. > My problem here is that you are substituting a perfectly working eclipse package > with a problematic package with the same name. The new package frees me from > being able to use the JVM I want (I used previously eclipse with BEA and Sun > JVMs without problems) and hurts me in one of the tools I use most of the day. This isn't really an Eclipse issue - it's a JPackage vs. Fedora issue. Eclipse isn't the only package that takes precedence over JPackage ones (tomcat5 and many jakarta ones do as well). I'm sorry that your experience has been less than satisfactory so far. Perhaps we should discuss the JPackage vs. Fedora java stuff issue on fedora-devel-java-list.
Well, I never claimed it was an Eclipse issue--it is a *Fedora* issue 8^). OK: I tried again the gcj-based version in a clean environment (rm -fr .eclipse etc.) and it worked BUT I got the same exceptions (log included), and editing libraries is still impossible. So it might be a milestone problem after all. I think that Fedora should find a way to run Eclipse by default with gcj, independently of the currently chosen jvm, and that the package should be marked clearly (e.g., eclipse-native). In the current setting, we are really running the risk of making Java difficult to use on Fedora. I haven't still fully grasped the extent and the implications of compiled libraries, but I've tried to run with gcj's java some of my classes, and I got various kinds of errors that do not happen with a JVM.
Created attachment 115553 [details] Eclipse log generated by gcj
Created attachment 115554 [details] A set of exported Eclipse libraries To replicate the bug easily, start a completely fresh version of Eclipse, import this user library file and try to edit or delete any jar entry.
(In reply to comment #9) > OK: I tried again the gcj-based version in a clean environment (rm -fr .eclipse > etc.) and it worked BUT I got the same exceptions (log included), and editing > libraries is still impossible. So it might be a milestone problem after all. It could also be a native-compilation issue. > I think that Fedora should find a way to run Eclipse by default with gcj, > independently of the currently chosen jvm, and that the package should be marked > clearly (e.g., eclipse-native). We've had many arguments about this. I personally really like the way that we do it now (ie. allowing anyone to run with whatever JVM they like via the alternatives system). https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155754 is probably the best way to differentiate ATM. I'd like to work on this but have much more pressing issues. > In the current setting, we are really running the risk of making Java > difficult to use on Fedora. I'm not really sure this is true. Can you comment further? > I haven't still fully grasped the extent and the implications > of compiled libraries, but I've tried to run with gcj's java some of > my classes, and I got various kinds of errors that do not happen with a JVM. I guess it just needs to be made pretty clear that gcj and GNU Classpath aren't feature-complete from an "everything works just like Sun's JDK" perspective. Bug reports would really help here, BTW: http://gcc.gnu.org/bugzilla :)
OK, I'll comment further. We are in a situation in which Fedora Core supports Eclipse *if* you use gcj; if you want to use another JVM, as you say, "While not explicitly "supported", this _should_ work." Since your package has the same name of a venerable JPackage package, it is difficult to keep the JPackage version (I don't even know exactly how this could be done), avoiding automatic upgrades. So I'm forced to use GCJ. As you say, however, 'gcj and GNU Classpath aren't feature-complete from an "everything works just like Sun's JDK" perspective.'. So I'm forced to use a Java implementation that gives me lots of issues with my present code. This is what I call "making Java difficult to use on Fedora". I have also some stuff, like the Lilypond Snippet Repository, working on the same box, and switching JVM causes problems, too. Note that I'm pretty happy of the fact that Fedora is supporting GCJ, and it is fantastic that this is done at the distribution level. But I don't think it is a good idea to force people to change systemwide the JVM using alternatives. If you want to distribute compiled stuff that is not explicitly supported on a non-compiled JVM, you should provide an alternative mechanism restricted to the group of natively compiled applications. Something like java-fedora or similar, that would switch the JVM just for the applications you tuned for GCJ. That's my 2 â¬cent 8^).
Is this still happening?
Closing due to lack of response.