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

[Kevin Rushforth]

Regarding the following JIRA issues:

http://javafx-jira.kenai.com/browse/RT-26125
http://ccc.us.oracle.com/8003171 (CCC for above work)

http://bugs.sun.com/view_bug.do?bug_id=8001533 (already implemented in 
the JDK)

As a heads-up, I plan to push the changes that will move jfxrt.jar from 
its present location in jre/lib to its new home in jre/lib/ext, 
hopefully in time for next week's EA build of JDK 8-b75. In conjunction 
with the recent launcher changes, this will have some impact that may be 
visible to applications (mostly in a good way, but there are some caveats).

1) jfxrt.jar will now be on the default application classpath used by 
javac and java (and javap, etc). This means self-packaged apps and apps 
run from class files no longer need to explicitly add jfxrt.jar to the 
classpath.

2) The java 8 launcher will now directly launch Java applictions from a 
jar file, even if they weren't created with the javafxpackager program 
or ant tasks. Further, the java launcher will now directly launch Java 
applictions from class files. In both of these cases the JavaFX 
application launcher will be called in preference to the main() method 
of the application's Main-Class.

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.

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.

Let me know if you have any questions.

-- Kevin