Community
Participate
Working Groups
Build Identifier: 20100917-0705 I am using CDT to develop in C++ on Fedora 11, which comes with JRE 1.6. Eclipse does not support this JRE version. It ran well enough to fool me, but there were some problems. When I finally caught on and installed Java 5, Eclipse and CDT performed much better. I saw a lot of questions in the forum that could very well be related to this basic mistake. You could reduce the support load by helping diagnose this problem. Please check the JRE version upon startup, and display a dialog if it is different. Of course add the usual "Do not display this again" button. Reproducible: Always Steps to Reproduce: 1. Use Java 1.6 2. Eclipse acts weird 3. Use Java 5 4. Eclipse rocks!
(In reply to comment #0) > I am using CDT to develop in C++ on Fedora 11, which comes with JRE 1.6. > > Eclipse does not support this JRE version. Actually, Java 6 is supported. http://www.eclipse.org/eclipse/development/readme_eclipse_3.6.1.html#TargetOperatingEnvironments I use Java 6 myself in fact. > It ran well enough to fool me, but there were some problems. What were these "problems" exactly?
(In reply to comment #1) > Actually, Java 6 is supported. > http://www.eclipse.org/eclipse/development/readme_eclipse_3.6.1.html#TargetOperatingEnvironments It says on the Eclipse download page (in the upper right) that java 5 is recommended: http://www.eclipse.org/downloads. Maybe something on eclipse.org is out of date. That's something about the dialog that is superior to web pages. When the developers start using a new JRE version, the dialog appears, and reminds them to update the software behind the dialog with the new recommended JRE version. > I use Java 6 myself in fact. > > > It ran well enough to fool me, but there were some problems. > > What were these "problems" exactly? My forum question describes my problem, CDT loses contact with gdb after a few commands [message #629642] The other problem I had was that Eclipse ran out of memory, but that was just once. The point of this enhancement request is to eliminate a large class of inscrutable problems related to the JRE version. It's so easy for Eclipse to check, yet difficult for me to diagnose.
I suspect the problem is that the JRE coming with Fedora is GCJ, which is not supported. See: http://www.eclipse.org/eclipse/development/readme_eclipse_3.6.html#I-General-GCJ Java 6 (HotSpot, JRockit, or IBM) is fully supported/recommended for running Eclipse. If you have issues on Java 6 that aren't seen on Java 5, please enter bugs against the relevant components.
(In reply to comment #3) > I suspect the problem is that the JRE coming with Fedora is GCJ, which is not supported. I believe that I am using whatever JRE came with Fedora 11. > http://www.eclipse.org/eclipse/development/readme_eclipse_3.6.html#I-General-GCJ A very informative page. The type of JRE is yet another dimension in the JRE version problem, and it too can be easily checked by Eclipse on startup to forestall inscrutable problems. To you who are Java programmers, all this JRE stuff is probably second nature. However, users like myself who use CDT are not so familiar with the components, versions and flavors of Java. Before this incident, I thought that any JRE would be as good as any another. Implementing this enhancement would really help Eclipse users who are not so up to date on Java.
(In reply to comment #2) > (In reply to comment #1) > > > Actually, Java 6 is supported. > > http://www.eclipse.org/eclipse/development/readme_eclipse_3.6.1.html#TargetOperatingEnvironments This page says that Java 6 is supported only for Windows 32 bit. I am on Fedora 11, so I'll stick with Java 5 update 22. This page shows that there is yet another dimension to JRE compatibility: platform. This page is actually the spec for this enhancement.
(In reply to comment #4) > Before this incident, I thought that any JRE > would be as good as any another. This is generally true. While there are discrepancies between the different JREs, they are often few and far between. In order to call yourself a Java runtime, your runtime and VM do have to pass a rigorous compatibility test so differences caused by differing JREs are not exactly phenomena that happen every day. I would do what John suggested in comment 3 and open a bug with the CDT team and/or against the people that you got your Java 6 runtime from. (In reply to comment #5) > (In reply to comment #2) > > (In reply to comment #1) > > > Actually, Java 6 is supported. > > > http://www.eclipse.org/eclipse/development/readme_eclipse_3.6.1.html#TargetOperatingEnvironments > > This page says that Java 6 is supported only for Windows 32 bit. I am on > Fedora 11, so I'll stick with Java 5 update 22. I see "Sun Java 6 Update 17" in the row for 32-bit x86 RHEL 5.0. Unless, the fact you wanted to point out was that Fedora 11 isn't listed on that page.
(In reply to comment #6) > > This page says that Java 6 is supported only for Windows 32 bit. I am on > > Fedora 11, so I'll stick with Java 5 update 22. My experience with Fedora is that I can look in the Red Hat Enterprise Linux row, and assume that it applies to Fedora. > I see "Sun Java 6 Update 17" in the row for 32-bit x86 RHEL 5.0. > > Unless, the fact you wanted to point out was that Fedora 11 isn't listed on > that page. You're right. Somehow I missed the Java 6 notation under 32 bit x86, but I'm using x86_64. So that's yet another dimension: CPU architecture.
Actually from review of bug 191254, we are supposed to be checking for GCJ and warning the user about it on startup. Can you run "java -version" against the Java version that comes with Fedora? Two possibilities come to mind: you're not using GCJ, or our detection of GCJ has been broken somehow.
On the JRE version dimension, there is currently a check in startup.jar to verify the VM version is >= the minimum version number. I suspect in your case the version is fine but the vendor may be different (or you're running into a genuine VM bug we haven't seen)..
(In reply to comment #8) > Actually from review of bug 191254, we are supposed to be checking for GCJ and > warning the user about it on startup. Can you run "java -version" against the > Java version that comes with Fedora? Two possibilities come to mind: you're not > using GCJ, or our detection of GCJ has been broken somehow. On Fedora 11: > which java /usr/bin/java > java -version java version "1.6.0_18" OpenJDK Runtime Environment (IcedTea6 1.8) (fedora-36.b18.fc11-x86_64) OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) So this is higher than the minimum version, but perhaps too high?
Thanks for bearing with us, this is good information. OpenJDK 6 is a strange beast - it is actually a backport of OpenJDK7 rather than a direct descendant of Sun's JDK 6. I have no good information on whether Eclipse is stable on this VM or not. Before we add any checks to warn/stop users from using this particular VM, can you provide more detail on the error? Did you have crashes, and do you have the resulting error logs?
(In reply to comment #2) > My forum question describes my problem, > > CDT loses contact with gdb after a few commands [message #629642] For context purposes, here is the link to the thread. http://www.eclipse.org/forums/index.php?t=msg&goto=630047
(In reply to comment #11) > Thanks for bearing with us, this is good information. OpenJDK 6 is a strange > beast - it is actually a backport of OpenJDK7 rather than a direct descendant > of Sun's JDK 6. I have no good information on whether Eclipse is stable on this > VM or not. Before we add any checks to warn/stop users from using this > particular VM, can you provide more detail on the error? Did you have crashes, > and do you have the resulting error logs? We (Fedora) have been shipping Eclipse runnint on OpenJDK 6 for a few years we haven't had stability issues related to OpenJDK. There are problems related to some other components like xulrunner and the onetime problem when gtk changed its rendering but nothing that is proved to be an OpenJDK problem.
There shouldn't any special checks for OpenJDK proved to be working.
Eclipse has -Dosgi.requiredJavaVersion=1.8 in eclipse.ini so min version is properly declared. Regarding different implementations so many things changed in the Java world lately that this one is just fixed for the sake of this bug.
