Bugzilla – Full Text Bug Listing
| Summary: | [9] Cannot launch JUnit Plugin test with Java 9 instead of Java 8 | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Till Brychcy <register.eclipse> |
| Component: | Debug | Assignee: | Sarika Sinha <sarika.sinha> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | daniel_megert, jarthana, sarika.sinha, Vikas.Chandra |
| Version: | 4.8 | ||
| Target Milestone: | 4.7.1a | ||
| Hardware: | PC | ||
| OS: | All | ||
| See Also: |
https://git.eclipse.org/r/104302 https://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=303ab53c0c4e979c5c5a8b414f451afe90979685 https://git.eclipse.org/r/105597 https://git.eclipse.org/r/105598 https://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=5dc3b41e97884a94e4037ca7ae78bc4a7c4d962c |
||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 522633 | ||
|
Description
Till Brychcy
New Gerrit change created: https://git.eclipse.org/r/104302 Thanks Till!! Gerrit change https://git.eclipse.org/r/104302 was merged to [BETA_JAVA9]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=303ab53c0c4e979c5c5a8b414f451afe90979685 Reopening this, Adding Vikas from PDE as plain junit tests and java applications are working. I investigated further - JUnitLaunchConfigurationDelegate in PDE Launching sets the classpath and bootclasspath. All the jars for path are actually set to bootclasspath. Even if JDT Launching stops the bootpath setting and avoids -Xbootclasspath error, it will not have the jars on the path and it fails(I tried out). For java9 configurations, either everything should go to classpath or be set on classpath and modulepath. (In reply to Sarika Sinha from comment #5) > I investigated further - > JUnitLaunchConfigurationDelegate in PDE Launching sets the classpath and > bootclasspath. > > All the jars for path are actually set to bootclasspath. > > Even if JDT Launching stops the bootpath setting and avoids -Xbootclasspath > error, it will not have the jars on the path and it fails(I tried out). Can we redirect such entries to classpath if the target VM is 9 or above? I know it's still not accurate, but if the clients of launch are unaware that -Xbootclasspath is not allowed, they are probably not aware of module path either, in which case, only place it can go to is classpath? Does it sounds reasonable? I thought about it Jay yesterday itself, but I could not find any place where there is a suggestion from Java9 that what was going in bootclasspath should go to classpath. May be this will be true for many cases but jdt launching can not bluntly just move it across. And only the respective component can provide exact order for paths. The components who want to support the1r launches with java9 need to react. On the launched eclipse workspace, I dont see this issue. On the base eclipse, I always get java.net.SocketException: Socket operation on nonsocket: configureBlocking at java.net.DualStackPlainSocketImpl.configureBlocking(Native Method) at java.net.DualStackPlainSocketImpl.socketAccept(Unknown Source) at java.net.AbstractPlainSocketImpl.accept(Unknown Source) at java.net.PlainSocketImpl.accept(Unknown Source) at java.net.ServerSocket.implAccept(Unknown Source) at java.net.ServerSocket.accept(Unknown Source) at org.eclipse.jdi.internal.connect.SocketTransportService.accept(SocketTransportService.java:98) at org.eclipse.jdi.internal.connect.SocketTransportImpl.accept(SocketTransportImpl.java:60) at org.eclipse.jdi.internal.connect.SocketListeningConnectorImpl.accept(SocketListeningConnectorImpl.java:164) Sometimes launch is not successful. ( not consistent way to recreate this) but if there is a mix of java8 plugins/project and java9 plugins/projects, it happens sometimes. Unfortunately I don't have a consistent way to recreating this. I am really not sure what is happening. New Gerrit change created: https://git.eclipse.org/r/105597 (In reply to Eclipse Genie from comment #9) > New Gerrit change created: https://git.eclipse.org/r/105597 I don't have time for a real analysis now, but I saw you are still researching this, so I thought, I'd post this patch (in jdt.debug), which fixes the problem, at least for the case I reported. Sometimes I get this error while launching ( debug launch) eclipse after creating a pde project with java 9 and 1 junit test case in it This is the launching error I get sometimes !STACK 1 org.eclipse.e4.core.di.InjectionException: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:410) at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:318) at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:162) at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultHeadlessContext(E4Application.java:491) at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createDefaultContext(E4Application.java:505) at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:204) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:614) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:336) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:594) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:148) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:151) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:653) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:590) at org.eclipse.equinox.launcher.Main.run(Main.java:1499) at org.eclipse.equinox.launcher.Main.main(Main.java:1472) Caused by: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:124) at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:399) ... 23 more Caused by: java.lang.ClassNotFoundException: javax.annotation.PostConstruct cannot be found by org.eclipse.e4.core.di_1.6.100.v20170421-1418 at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:433) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387) at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496) ... 25 more !ENTRY org.eclipse.e4.ui.workbench 4 0 2017-09-22 14:07:11.908 !MESSAGE FrameworkEvent ERROR !STACK 0 java.lang.NoClassDefFoundError: javax/annotation/PreDestroy at org.eclipse.e4.core.internal.di.InjectorImpl.disposed(InjectorImpl.java:450) at org.eclipse.e4.core.internal.di.Requestor.disposed(Requestor.java:156) at org.eclipse.e4.core.internal.contexts.ContextObjectSupplier$ContextInjectionListener.update(ContextObjectSupplier.java:78) at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.update(TrackableComputationExt.java:111) at org.eclipse.e4.core.internal.contexts.TrackableComputationExt.handleInvalid(TrackableComputationExt.java:74) at org.eclipse.e4.core.internal.contexts.EclipseContext.dispose(EclipseContext.java:178) at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.dispose(EclipseContextOSGi.java:99) at org.eclipse.e4.core.internal.contexts.osgi.EclipseContextOSGi.bundleChanged(EclipseContextOSGi.java:141) at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:908) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:213) at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:120) at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112) at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:168) at org.eclipse.osgi.container.Module.publishEvent(Module.java:476) at org.eclipse.osgi.container.Module.doStop(Module.java:634) at org.eclipse.osgi.container.Module.stop(Module.java:498) at org.eclipse.osgi.container.SystemModule.stop(SystemModule.java:202) at org.eclipse.osgi.internal.framework.EquinoxBundle$SystemBundle$EquinoxSystemModule$1.run(EquinoxBundle.java:165) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.lang.ClassNotFoundException: javax.annotation.PreDestroy cannot be found by org.eclipse.e4.core.di_1.6.100.v20170421-1418 at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:433) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387) (In reply to Till Brychcy from comment #10) > (In reply to Eclipse Genie from comment #9) > > New Gerrit change created: https://git.eclipse.org/r/105597 > > I don't have time for a real analysis now, but I saw you are still > researching this, so I thought, I'd post this patch (in jdt.debug), which > fixes the problem, at least for the case I reported. Thanks Till. This just stops the Xbootclasspath error. But required jars has to be put on the path like nirmal JUnit test case getClasspath() does. PDE getClasspath() just returns equinox in the path. It needs to add up the other classpath entries. (In reply to Vikas Chandra from comment #11) > Sometimes I get this error while launching ( debug launch) eclipse after > creating a pde project with java 9 and 1 junit test case in it > > This is the launching error I get sometimes > > !STACK 1 > org.eclipse.e4.core.di.InjectionException: java.lang.NoClassDefFoundError: > javax/annotation/PostConstruct > at > org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java: > 410) > at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:318) > at > org.eclipse.e4.core.contexts.ContextInjectionFactory. > make(ContextInjectionFactory.java:162) > at > org.eclipse.e4.ui.internal.workbench.swt.E4Application. > createDefaultHeadlessContext(E4Application.java:491) > at > org.eclipse.e4.ui.internal.workbench.swt.E4Application. > createDefaultContext(E4Application.java:505) You need to add --add-modules=ALL-SYSTEM in vm arguments https://marketplace.eclipse.org/content/java-9-support-beta-oxygen One question that I have: Why don't I see this in the last week's Y build? (In reply to Sarika Sinha from comment #12) > (In reply to Till Brychcy from comment #10) > > (In reply to Eclipse Genie from comment #9) > > > New Gerrit change created: https://git.eclipse.org/r/105597 > > > > I don't have time for a real analysis now, but I saw you are still > > researching this, so I thought, I'd post this patch (in jdt.debug), which > > fixes the problem, at least for the case I reported. > > > Thanks Till. > This just stops the Xbootclasspath error. But required jars has to be put on > the path like nirmal JUnit test case getClasspath() does. PDE getClasspath() > just returns equinox in the path. It needs to add up the other classpath > entries. Hmm with this patch, the tests launch successfully for me. So I guess there is another problem for a setup which different as described in comment #0, if yes, maybe there should be another bug for this? New Gerrit change created: https://git.eclipse.org/r/105598 (In reply to Eclipse Genie from comment #16) > New Gerrit change created: https://git.eclipse.org/r/105598 We don't need to calculate Bootpath for Modular vms. (In reply to Jay Arthanareeswaran from comment #14) > One question that I have: Why don't I see this in the last week's Y build? https://git.eclipse.org/r/104302 Made the run configurations to use project's JRE which is 8 in your case. I can confirm both the patches (from Till and Sarika) fixes my scenario. Yes, so for many cases bootclasspath is not set and it will work so I will fix this with e mentioned change. Created Bug 522633 for PDE changes to be done. Working on some tests which expect bootpath Bug 522633 works for me with org.eclipse.jdt.launching patch Please check other java launch delegate based configurations like m2e as well with the patch. Right now, I cannot launch an m2e configuration even using a 1.8 jre Gerrit change https://git.eclipse.org/r/105598 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=5dc3b41e97884a94e4037ca7ae78bc4a7c4d962c Noo getBootpath will return null for run configurations running on Java9 and above. Changed the boothpath testcases to adapt to it. >>--add-modules=ALL-SYSTEM in vm arguments
Not on 4.7.1a builds
Thankfully this problem is fixed in later 4.7.1a builds. (eclipse.ini in later builds have this).
(In reply to Vikas Chandra from comment #26) > >>--add-modules=ALL-SYSTEM in vm arguments > > Not on 4.7.1a builds > > Thankfully this problem is fixed in later 4.7.1a builds. (eclipse.ini in > later builds have this). NOTE: - this will currently not be there if you use an EPP - it is there if you use recent I-builds (In reply to Sasikanth Bharadwaj from comment #23) > Please check other java launch delegate based configurations like m2e as > well with the patch. Right now, I cannot launch an m2e configuration even > using a 1.8 jre Will Sarika's fix this one too? (In reply to Jay Arthanareeswaran from comment #28) > (In reply to Sasikanth Bharadwaj from comment #23) > > Please check other java launch delegate based configurations like m2e as > > well with the patch. Right now, I cannot launch an m2e configuration even > > using a 1.8 jre > > Will Sarika's fix this one too? We are working on that, that's a separate issue all together Bug 522333 |