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

[Kevin Rushforth]

My thinking on the source location -- which is tracked by 
http://javafx-jira.kenai.com/browse/RT-21415 -- is that we will create a 
javafx-src.zip file in the top-level JDK directory along-side src.zip. I 
hope to do this within the next few weeks.

-- Kevin


Tom Schindl wrote:
> Is there any progress on the source-location? Would be nice to know in
> advance where it it will endup, so that once it is there the IDE will
> detect it?
>
> The missing JavaDoc/Source is still a major pain in IDEs!
>
> Tom
>
> Am 25.01.13 01:51, schrieb Kevin Rushforth:
>   
>> That seems best to me, too. Thanks.
>>
>> Another reason not to delay is that the recent java launcher changes,
>> which were integrated into last week's build, have caused of regression
>> in launching JavaFX-packaged applications. So I think there is no good
>> alternative to getting this into next week's build.
>>
>> -- Kevin
>>
>>
>> Tom Schindl wrote:
>>     
>>> Hi,
>>>
>>> It depends on how fast you can make this split happen.
>>>
>>> The earlier we have javafxrt.jar on the ext-classpath the better. Yes,
>>> there is likeliness that we break some SWT stuff temporary instead of
>>> leaving 95% of the JavaFX users in the dust.
>>>
>>> This is Java8 and this is not the only thing that breaks with builds ;-)
>>>
>>> My take would be:
>>> a) proceed with moving javafxrt.jar on ext-classpath
>>> b) work with accelerated speed to fix the swt issue
>>>    (Equinox user currently won't be hurt)
>>>
>>> Tom
>>>
>>> Am 24.01.13 20:23, schrieb 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
>>>>
>>>>     
>>>>         
>>>   
>>>       
>
>
>