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

[Kevin Rushforth]

Richard Bair wrote:
>>>> 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.
>>
>> Bootclassloader
>>  + 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.
>>     
>
> Does this mean that you can't use the FXCanvas in an OSGI based application?

If I understand correctly, it means that the short-term workaround of 
putting swt.jar on the boot classpath won't be a very effective workaround.

Perhaps we need to accelerate the separation of the javafx.embed.swt 
classes from jfxrt.jar (or delay moving jfxrt.jar into lib/ext).

-- Kevin