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

[Tom Schindl]

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
>>>
>>>     
>>
>>
>>   


-- 
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