JDK-8152839 : Java WebStart throws ClassNotFoundException when attempting to link to JAXB type
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 9
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2016-03-26
  • Updated: 2017-07-05
  • Resolved: 2016-04-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b116Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
Java(TM) SE Runtime Environment (build 9-ea+111)
Java HotSpot(TM) Client VM (build 9-ea+111, mixed mode)


A DESCRIPTION OF THE PROBLEM :
A small WebStart client throws a ClassNotFoundException despite compiling properly - it also executes correct with the Java 9 JRE when execute normally.

Seems similar to JI-9033432 but the error is different, this bug doesn't talk about module exports.

REGRESSION.  Last worked in version 9

ADDITIONAL REGRESSION INFORMATION: 
Java(TM) SE Runtime Environment (build 9-ea+111)
Java HotSpot(TM) Client VM (build 9-ea+111, mixed mode)


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Deploy the suggested class as a webstart client

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The webstart application should execute normally
ACTUAL -
ClassNotFoundException 

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.ClassNotFoundException: javax.xml.bind.JAXBException
	at com.sun.deploy.security.DeployURLClassLoader.findClass(jdk.deploy@9-ea/DeployURLClassLoader.java:301)
	at com.sun.jnlp.JNLPClassLoader.findClass(jdk.javaws@9-ea/JNLPClassLoader.java:372)
	at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:486)
	at java.lang.ClassLoader.loadClass(java.base@9-ea/ClassLoader.java:419)
	at Test.main(Test.java:5)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
	at com.sun.javaws.Launcher.executeApplication(jdk.javaws@9-ea/Launcher.java:1780)
	at com.sun.javaws.Launcher.executeMainClass(jdk.javaws@9-ea/Launcher.java:1715)
	at com.sun.javaws.Launcher.doLaunchApp(jdk.javaws@9-ea/Launcher.java:1563)
	at com.sun.javaws.Launcher.run(jdk.javaws@9-ea/Launcher.java:164)
	at java.lang.Thread.run(java.base@9-ea/Thread.java:804)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.xml.bind.JAXBException;

public class Test {
        public static void main(String[] args) {
                new JAXBException("");
        }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
None found


Comments
verified by running manual test case JavawsInteropManual::testJAXB on Windows 7 / 9b176
05-07-2017

On 01/04/2016 07:25, stephen hu wrote: > I did a quick search in our test code base for string "ALL-SYSTEM", nothing found. > > So does java.instrument somehow imply "ALL-SYSTEM"? Yes, because -javaagent:<agent> means there can be arbitrary code in the unnamed module executed. -Alan
01-04-2016

I seem to have found the real difference In manual mode, we have property jdk.launcher.addmods=javafx.web,javafx.fxml,javafx.deploy,java.se,javafx.swing while in auto mode, the property is jdk.launcher.addmods=javafx.web,javafx.fxml,javafx.deploy,java.se,javafx.swing,java.instrument,ALL-SYSTEM
01-04-2016

I'm able to reproduce the issue manually. However, I could not reproduce it in automation test. The major difference between auto and manual mode is that in auto test we have automation drive jar in the form of javaagent. I printed out the class loader information for JAXBException. In auto mode, it is jdk.internal.loader.ClassLoaders$PlatformClassLoader@16995df. Not sure if this is caused by the existence of javaagent drive jar, which anyway is an integral part of our automation testing.
01-04-2016

Web start needs to be launcher with `-addmods ALL-SYSTEM`.
28-03-2016