JDK-7183866 : Cannot load JavaFX classes when prepending jfxrt.jar via -Xbootclasspath/p
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7u6
  • Priority: P1
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2012-07-13
  • Updated: 2012-07-14
  • Resolved: 2012-07-14
Related Reports
Relates :  
Description
Prepending the JavaFX runtime library onto the bootclasspath fails with JDK 7u6 causing NetBeans Swing interop projects to fail.

The original NetBeans bug is filed here: http://netbeans.org/bugzilla/show_bug.cgi?id=214386

The NetBeans team then filed a JavaFX bug here:
http://javafx-jira.kenai.com/browse/RT-22679

The easiest way to reproduce this is to compile the attached program as follows:

"C:\Program Files (x86)\Java\jdk1.7.0_06\bin\javac.exe" -cp "C:\Program Files (x86)\Java\jdk1.7.0_06\jre\lib\jfxrt.jar" SimpleFXApp.java

And the run it as follows:

"C:\Program Files (x86)\Java\jdk1.7.0_06\bin\java.exe" -Xbootclasspath/p:"C:\Program Files (x86)\Java\jdk1.7.0_06\jre\lib\jfxrt.jar" -classpath . SimpleFXApp

It will fail with the following CNFE:

Exception in thread "main" java.lang.NoClassDefFoundError: javafx/scene/Group
        at SimpleFXApp.main(SimpleFXApp.java:6)
Caused by: java.lang.ClassNotFoundException: javafx.scene.Group
        at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
        ... 1 more

Comments
EVALUATION For a variety of technical and policy reasons, putting FX on the bootclasspath in the JDK distrubtion of 7u6 was declined. Putting the jar files on the bootclasspath via the IDE is very suspect. Closing as will not fix until technical justification is provided for having the jar be on the bootclasspath, as opposed to the normal classpath or in an extension directory.
14-07-2012