Bug 810568 - Eclipse 4.2 fails to start when using Java 6
Eclipse 4.2 fails to start when using Java 6
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
rawhide
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Krzysztof Daniel
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-06 14:29 EDT by Severin Gehwolf
Modified: 2014-01-12 19:26 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-10 12:53:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Severin Gehwolf 2012-04-06 14:29:13 EDT
Description of problem:
I have rawhide Eclipse installed and had an old workspace with with only a Java 6 execution environment configured. When I attempted to start a child Eclipse instance, it failed with:
java.lang.UnsupportedClassVersionError: javax/inject/Singleton : Unsupported major.minor version 51.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:188)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClassHoldingLock(ClasspathManager.java:632)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:614)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:568)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:492)
	at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:465)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
	at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:395)
	at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:35)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:452)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
	at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:279)
	at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:240)
	at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:161)
	at org.eclipse.e4.core.services.translation.TranslationProviderFactory.bundleTranslationService(TranslationProviderFactory.java:34)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultHeadlessContext(E4Application.java:410)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultContext(E4Application.java:427)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:179)
	at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:549)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:535)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
	at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
	at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
	at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:616)
	at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1414)


Version-Release number of selected component (if applicable):
$ rpm -q eclipse-platform
eclipse-platform-4.2.0-0.5.fa15ab.fc18.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Switch system Java to version 6.
2. Attempt to start Eclipse
  
Actual results:
Above stack trace.

Expected results:
Eclipse starts.

Additional info:
I suppose this is due to Eclipse being compiled in koji with Java 7 and there is a @Singleton annotation somewhere in the Eclipse code which during runtime tries to use Java 6's implementation of it and hence byte code verification fails. I see two options to fix this:

1.) Compile Eclipse 4.2 with Java 6 (if that's even possible)
2.) Add an explicit "Requires" for Java 7

Thoughts?
Comment 1 Andrew Overholt 2012-04-09 08:40:53 EDT
Shouldn't the BREEs take care of this?
Comment 2 Krzysztof Daniel 2012-04-10 03:47:49 EDT
After chat with Alex:
* f17 will not include java 6
* too many Eclipse dependencies uses java 7, and the exception may be caused by them at any time

Fix for this bug (commit f5467997c8677ce584b83784c2b76e79b026f49f) has been released, but the Eclipse will be built and pushed before the end of the week (13-04-2012). This bug will be opened until that time.
Comment 3 vitkecar 2012-07-01 07:09:31 EDT
This bug is still present today, with an up-to-date Fedora.
Comment 4 Alexander Kurtakov 2012-07-02 05:01:52 EDT
There is no Java 6 implementation in Fedora 17+, all dependencies are build against Java 7, most upstreams do not set their target version in build systems and contain Java 7 bytecode in their default builds. 
Because of all that I'm closing the bug as won't fix as we (Eclipse maintainers) do not have the time to audit all the libraries in Fedora to set their target and there is no supported Java 6 runtime so we can not test it.

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