Bugzilla – Full Text Bug Listing
| Summary: | [9] Java 9 Application Start Delivers NullPointerException | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Chris masked <chris21k> | ||||||
| Component: | Debug | Assignee: | Sarika Sinha <sarika.sinha> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | daniel_megert, jarthana, noopur_gupta, sarika.sinha, scott.molling | ||||||
| Version: | 4.7.1 | ||||||||
| Target Milestone: | 4.7.1a | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 10 | ||||||||
| See Also: |
https://git.eclipse.org/r/106135 https://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=40f63e10c26a0e4b0da854e36506a89852a88803 https://git.eclipse.org/r/106402 https://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=292e22c882bf2db7e369d28f3da6d586ff926027 |
||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
I can't reproduce this with a build with similar timestamp (but a full SDK build - M20170927-1700). When I imported, I get couple of build path errors, because I have no library container named jre-9. Then I renamed one of the JRE 9 to jre-9 and the errors went away. No NPE in the logs. Could you try a full SDK build too, just to be sure? Sarika, What are the chances of findPackageFragmentRoot() returning null? Should we account for that case, just like we do in the other instance in JavaRuntime, line number 1528? Created attachment 270763 [details]
Screenshot of Message Box
@Jay: Thanks for your immediate answer. I used/always use a full SDK build. Now I tried again with the latest Eclipse SDK Version: Oxygen.1a (4.7.1a) Build id: M20170928-1310 from http://ftp-stud.fht-esslingen.de/pub/Mirrors/eclipse/eclipse/downloads/drops4/M-4.7.1aRC2-201709281310/eclipse-SDK-4.7.1aRC2-win32-x86_64.zip and exported the project, removed it, and imported it again. Then, e.g., just right click on TestPair.java -> Run as -> Java Application . The same thing, and here perfectly reproducable. I provide as attachement to this report of a screenshot of the error message box. Chris I am seeing the same issue. Version: Oxygen.1a (4.7.1a) Build id: U20170927-0115 I am seeing this with Oracle's released jdk-9. My PC is Windows 7. I have two projects, one much larger than the other, and this is only happening with the larger project. Not sure in which case, findPackageFragmentRoot can be null Jay. Can anyone add a sample project to help us understand. I think we should add a safeguard check for null there, but can we put it in RC3 ? The attached project is the smallest one such that I can reproduce the bug. If I do not use JAXB as external jars and one (the api) as module, but use the in JRE 9 integrated module of it with (--add-module java.xml.bind, i.e., with the gui of eclipse for the compile and run classpath) then the exception does not show. The first variant, however, is like the JAXB website suggests to use it with Java 9, or at least via --upgrade-module-path . I do not see, how to use upgrade instead of add for modules in eclipse so far. Maybe it is also related to starting eclipse itsef with Java 8 and only the project with 9. Unfortunately, JRE 9 silently stops, if one uses deprecated stuff like endorsed directory command line switches, which could also be related. Chris After debugging I see, Project Resolved path gets many entries and in them two are jaxb-api.jar and jaxb-api-2.3.0. So jaxb-api-2.3.0.jar is not a problem and we get findPackageFragmentRoot but for jaxb-api.jar we don't get it but surprising fact is from where is jaxb-api.jar coming as I don't see in build path. (In reply to Sarika Sinha from comment #7) > After debugging I see, Project Resolved path gets many entries and in them > two are > jaxb-api.jar and jaxb-api-2.3.0. > > So jaxb-api-2.3.0.jar is not a problem and we get findPackageFragmentRoot > but for jaxb-api.jar we don't get it but surprising fact is from where is > jaxb-api.jar coming as I don't see in build path. Perhaps it is being referenced by another JAR in the build path via Jar's Manifest? Yes Jay, I can see in jaxb-core-2.3.0.jar Class-Path: jaxb-api.jar New Gerrit change created: https://git.eclipse.org/r/106135 Gerrit change https://git.eclipse.org/r/106135 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=40f63e10c26a0e4b0da854e36506a89852a88803 Okay, to sum it up, there were a bunch of non-existing JAR files being referenced from manifest. Because these don't have underlying resources, it is normal for IJavaProject.findPackageFragmentRoot(IPath) to return null and this is documented as well. So, the best we can do here is to add a null check, which is what the last patch from Sarika does. New Gerrit change created: https://git.eclipse.org/r/106402 Gerrit change https://git.eclipse.org/r/106402 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=292e22c882bf2db7e369d28f3da6d586ff926027 M20171009-0410 - Import project from comment #0. - Set its JRE System Library to EE JavaSE-9. - Run As > Java Application on TestPair.java. => I am getting this exception: Exception in thread "main" java.lang.NoClassDefFoundError: javax/activation/DataSource at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl.<clinit>(RuntimeBuiltinLeafInfoImpl.java:478) at com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.<init>(RuntimeTypeInfoSetImpl.java:63) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:128) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:84) at com.sun.xml.bind.v2.model.impl.ModelBuilder.<init>(ModelBuilder.java:162) at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.<init>(RuntimeModelBuilder.java:92) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:455) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:303) at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:139) at com.sun.xml.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1156) at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:165) 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 javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:297) at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:286) at javax.xml.bind.ContextFinder.find(ContextFinder.java:409) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:721) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:662) at javax.xml.bind.JAXB$Cache.<init>(JAXB.java:127) at javax.xml.bind.JAXB.getContext(JAXB.java:154) at javax.xml.bind.JAXB.unmarshal(JAXB.java:238) at TestPair.read(TestPair.java:43) at TestPair.main(TestPair.java:98) Caused by: java.lang.ClassNotFoundException: javax.activation.DataSource at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496) ... 25 more (In reply to Noopur Gupta from comment #15) > M20171009-0410 This is because I was not adding --add-modules=java.xml.bind while launching. After adding it, the scenario works. |
Created attachment 270749 [details] Example Project I am using the latest build U20170927-0115, Java 8 to start it and the first release of Oracle Java 9 for the project. Importing and starting the attached project (TestPair.java) which uses an external Java 9 module (jaxb-api.jar) and some other (traditional) jars on the classpath (jaxb-*.jar) delivers a NullPointerException of Eclipse. Here is the entry of the .log file: !SESSION 2017-09-29 07:28:29.636 ----------------------------------------------- eclipse.buildId=4.7.1.U20170927-0115 java.version=1.8.0_144 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE Command-line arguments: -os win32 -ws win32 -arch x86_64 !ENTRY org.eclipse.egit.ui 2 0 2017-09-29 07:28:35.251 !MESSAGE Warning: The environment variable HOME is not set. The following directory will be used to store the Git user global configuration and to define the default location to store repositories: 'C:\Users\chris'. If this is not correct please set the HOME environment variable and restart Eclipse. Otherwise Git for Windows and EGit might behave differently since they see different configuration options. This warning can be switched off on the Team > Git > Confirmations and Warnings preference page. !ENTRY org.eclipse.core.jobs 4 2 2017-09-29 07:28:47.218 !MESSAGE An internal error occurred during: "Launching TestPair". !STACK 0 java.lang.NullPointerException at org.eclipse.jdt.launching.JavaRuntime.computeUnresolvedRuntimeDependencies(JavaRuntime.java:954) at org.eclipse.jdt.launching.StandardClasspathProvider.computeUnresolvedClasspath(StandardClasspathProvider.java:53) at org.eclipse.jdt.launching.JavaRuntime.computeUnresolvedRuntimeClasspath(JavaRuntime.java:1502) at org.eclipse.jdt.launching.AbstractJavaLaunchConfigurationDelegate.getBootpathExt(AbstractJavaLaunchConfigurationDelegate.java:299) at org.eclipse.jdt.launching.AbstractJavaLaunchConfigurationDelegate.getVMSpecificAttributesMap(AbstractJavaLaunchConfigurationDelegate.java:615) at org.eclipse.jdt.launching.JavaLaunchDelegate.launch(JavaLaunchDelegate.java:71) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1039) at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1256) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)