HEADS-UP: jfxrt.jar moving to jre/lib/ext

Tom Schindl tom.schindl at bestsolution.at
Thu Jan 24 09:42:49 PST 2013

Am 24.01.13 18:25, schrieb Richard Bair:
>> 3) Tools, scripts, programs that "know" where jfxrt.jar is relative to the root of the JRE will have to be adjusted accordingly, to either look for it in lib/ext or, if appropriate, just rely on the fact that it is now on the classpath. For example, when opening a JavaFX project in NB 7.2, it may not recognize your JDK8 as being JavaFX-capable. A future version of NB will add support for JDK 8 / FX 8.
> We should make sure this is posted widely and easily discoverable via Google searches on "why doesn't Java 8 work with FX" or something along those lines.
>> 4) Because we still include the javafx.embed.swt package in jfxrt.jar -- see http://javafx-jira.kenai.com/browse/RT-23041 -- applications that access javafx.embed.swt.FXCanvas will need to put the swt.jar library on the boot classpath in order for it to run.
> Putting swt.jar on the normal class path won't cut it?

If get classloaders right no.

  + Extclassloader
    + ApplicationClassloader

So Extclassloader can only see classes from Bootclassloader for normal
Java-SWT apps SWT on the bootclassloader will do it, for SWT-OSGi apps
(which is the majority out there) this will cause extrem troubles
because they ship swt as an OSGi-Bundle and we'll suddenly have 2
SWT-Jars on the classpath then:

* FXCanvas will load the one from the bootclasspath
* Java-Code will load the one from the OSGi-Application-Classpath

=> The application will blow up completely, so for SWT-OSGi-Application
giving the advice to put it on the bootclasspath is a very bad idea.


B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
tom schindl                 geschäftsführer/CEO
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834

More information about the openjfx-dev mailing list