Bug 810568

Summary:	Eclipse 4.2 fails to start when using Java 6
Product:	[Fedora] Fedora	Reporter:	Severin Gehwolf <sgehwolf>
Component:	eclipse	Assignee:	Krzysztof Daniel <kdaniel>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	akurtako, andjrobins, kdaniel, mbenitez, overholt, rgrunber, sgehwolf, swagiaal, vitkecar
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-04-10 16:53:07 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Severin Gehwolf 2012-04-06 18:29:13 UTC

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 12:40:53 UTC

Shouldn't the BREEs take care of this?

Comment 2 Krzysztof Daniel 2012-04-10 07:47:49 UTC

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 11:09:31 UTC

This bug is still present today, with an up-to-date Fedora.

Comment 4 Alexander Kurtakov 2012-07-02 09:01:52 UTC

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.