Bug 160626 - Eclipse does not edit libraries, does not make Undo/Redo, and more.
Eclipse does not edit libraries, does not make Undo/Redo, and more.
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Andrew Overholt
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-16 03:15 EDT by vigna
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-05 16:41:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Eclipse log (553.60 KB, text/plain)
2005-06-16 03:17 EDT, vigna
no flags Details
Eclipse log generated by gcj (5.95 KB, text/plain)
2005-06-16 12:52 EDT, vigna
no flags Details
A set of exported Eclipse libraries (4.12 KB, text/xml)
2005-06-16 12:54 EDT, vigna
no flags Details

  None (edit)
Description vigna 2005-06-16 03:15:09 EDT
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:
Comment 1 vigna 2005-06-16 03:17:06 EDT
Created attachment 115524 [details]
Eclipse log
Comment 2 Andrew Overholt 2005-06-16 09:48:28 EDT
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.
Comment 3 vigna 2005-06-16 10:03:36 EDT
A new *workspace*? Sorry, can't afford that. I'll wait patiently, hoping in the
updates.
Comment 4 vigna 2005-06-16 10:11:56 EDT
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? 
Comment 5 Andrew Overholt 2005-06-16 10:13:12 EDT
(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>
Comment 6 Andrew Overholt 2005-06-16 10:15:51 EDT
(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?
Comment 7 vigna 2005-06-16 10:35:22 EDT
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.
Comment 8 Andrew Overholt 2005-06-16 11:49:18 EDT
(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.
Comment 9 vigna 2005-06-16 12:48:11 EDT
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.
Comment 10 vigna 2005-06-16 12:52:50 EDT
Created attachment 115553 [details]
Eclipse log generated by gcj
Comment 11 vigna 2005-06-16 12:54:07 EDT
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.
Comment 12 Andrew Overholt 2005-06-16 14:51:28 EDT
(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 :)
Comment 13 vigna 2005-06-18 03:49:53 EDT
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^).
Comment 14 Andrew Overholt 2005-12-02 15:33:32 EST
Is this still happening?
Comment 15 John Thacker 2006-05-05 16:41:48 EDT
Closing due to lack of response.

Note You need to log in before you can comment on or make changes to this bug.