JDK-8102614 : Need to move jfxrt.jar from lib/ to lib/ext/
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: javafx
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2012-11-08
  • Updated: 2015-06-16
  • Resolved: 2013-01-30
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 8
8Fixed
Related Reports
Blocks :  
Blocks :  
Blocks :  
Blocks :  
Relates :  
Relates :  
Relates :  
Description
FX is cobundled with JDK 7u6 and later on all platforms. To complete this, we need to add jfxrt.jar to lib/ext so that it will be on the classpath by default. 

Comments
It was done. Close as verified.
30-12-2013

A regression: JDK 1.7 JavaFX 2 compiled applications now fail to locate the jfxrt.jar when the application is run on a OpenJFX 8 system. Problem observed at the raspberry pi forum: http://www.raspberrypi.org/phpBB3/viewtopic.php?p=408391#p408391 Can we back-port the RT-26125 fix http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/248c92889c2f to the OpenJFX u2 in order to let future JDK 1.7 JavaFX 2 compiled applications aware of the new, alternative, jfxrt.jar location used by OpenJFX/JavaFX 8 and later? An alternative fix may be to place a jfxrt.jar symlink inside the OpenJFX 8 jre/lib folder that points to the new jre/lib/ext/jfxrt.jar location, for backward compatibility with old JavaFX 2 Main launchers. Without a fix OpenJFX/JavaFX 8 users will be requested, by the old JavaFX 2 Main launcher, to download the latest runtime version despite that the user is already using the latest version.
20-08-2013

Yes it is. The packager does not require you to package up a JRE/JDK you can produce pure .jar-Files with some extra meta information (it replaces the main attribute!). How to package swing apps see https://blogs.oracle.com/talkingjavadeployment/entry/packaging_swing_apps_with_integrated
11-02-2013

My application is not a JavaFX app. It's a large Swing app to which I am adding some JavaFX components via JFXPanel. It is built by the Export Jar option in eclipse. I'd rather not redistribute javafx with my app if it's already in the jre/jdk. Will the javafx packager work in this case?
11-02-2013

The javafx packager does that for you if you use it to package up your application, why do you need it on the bootclasspath?
11-02-2013

Is there no hope of it being fixed in JDK/JRE 7 then? The promise of a bundled javafx is rather hollow without it. I'm working around it at present by using a launcher that tries to load the JFXPanel.class and adds jfxrt.jar to the boot classpath of my app if it can't. I hope that is unlikely to break in future. It does rely on the -Xbootclasspath/a switch though.
11-02-2013

Correct, this is for JDK 8.
11-02-2013

@Julian Fix version is "Lombard", so, it appears to be in 8.0.
11-02-2013

So if this is resolved, and jfxrt.jar is now supposed to be in lib/ext, when will this change propagate to the standard distribution? I just grabbed jre1.7.0_13 a few seconds ago and jfxrt.jar is still in lib.
11-02-2013

As a result of doing this, NetBeans JavaFX projects will stop working. There is a NB issue filed to add the necessary support: http://netbeans.org/bugzilla/show_bug.cgi?id=225326
25-01-2013

Raise to critical since this is needed to resolve RT-27902
25-01-2013

We do plan to address RT-23041 in FX 8, but we are not yet sure exactly how or when we will do that. So yes, in the short term, putting jfxrt.jar in lib/ext won't solve the problem for people using SWT (and may require you to do an additional step as a workaround).
24-01-2013

In RT-14479 you say that no further action is planned. If you are putting jfxrt.jar to lib/ext and you are not adressing RT-23041 the useage of the SWT-Bridge in OSGi will suffer and require once more extra hacks.
23-01-2013