javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135

[Kevin Rushforth]

I can't speak to what Tom is expecting, but javafx-swt.jar will not be 
an explicit module. It will be delivered as an automatic (implicit) 
module. This is required because swt.jar is not modularized.

The proposed approach of loading this into a Layer defined by the 
OSGi-Adapter-Hook should work without the javafx-swt.jar file needing to 
have a module-info.class file (at least the Jigsaw team believes that it 
will work). This still needs to be tested.

-- Kevin


Alexander Nyssen wrote:
> Tom, 
>
> just to make that explicit: you expected it to be shipped as an explicit and not as an automatic, implicit module by the OpenJFX team?
>
> Regards,
> Alexander
>
>   
>> Am 14.09.2016 um 09:26 schrieb Tom Schindl <tom.schindl at bestsolution.at>:
>>
>> I expect javafx.swt to be shipped with the jdk/jre - i can not repackage and ship openjfx code from eclipse.org
>>
>> Tom
>>
>> Von meinem iPhone gesendet
>>
>>     
>>> Am 14.09.2016 um 08:51 schrieb Alexander Nyssen <alexander at nyssen.org>:
>>>
>>> Hi Tom, Kevin,
>>>
>>> I have to admit that - now - I am somehow confused. At first glance "the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer“ and "it will not be an autom[at]ic-module but a named one loaded in a […] layer“ sounds like a contradiction. Tom, did you plan to „repackage“ the automatic (and thus implicitly defined) javafx.swt module as an explicit one as part of e(fx)clipse, or did you - like me - expect that javafx.swt will yet be turned into an explicit module by the OpenJFX team?
>>>
>>> Best Regards,
>>> Alexander
>>>
>>>       
>>>> Am 14.09.2016 um 00:51 schrieb Tom Schindl <tom.schindl at bestsolution.at>:
>>>>
>>>> Hi,
>>>>
>>>> javafx.swt can never be a module loaded by default but we need to
>>>> construct a new layer who has the SWT-Bundle-Classloader as the parent.
>>>>
>>>> So no it will not be an automic-module but a named one loaded in a
>>>> secondary layer (eg by the efxclipse OSGi-Adapter-Hook) - at least this
>>>> is the theory. I didn't have time yet to follow this path yet.
>>>>
>>>> Tom
>>>>
>>>>         
>>>>> On 13.09.16 20:31, Alexander Nyssen wrote:
>>>>> Hi Kevin,
>>>>>
>>>>>           
>>>>>> Am 13.09.2016 um 16:30 schrieb Kevin Rushforth <kevin.rushforth at oracle.com>:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Alexander Nyssen wrote:
>>>>>>             
>>>>>>> Hi Kevin,
>>>>>>>
>>>>>>>               
>>>>>>>> Am 13.09.2016 um 15:42 schrieb Kevin Rushforth <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>:
>>>>>>>>
>>>>>>>> That seems surprising since javafx.swt is not part of the JDK runtime image. I suspect that this is either an issue with jdeps itself or with how you are running jdeps. What was the command line you were using?
>>>>>>>>                 
>>>>>>> I used: for i in */bin; do /Library/Java/JavaVirtualMachines/jdk-9_ea135.jdk/Contents/Home/bin/jdeps -jdkinternals $i; done >> deps.txt
>>>>>>>               
>>>>>> That doesn't show how javafx-swt.jar is being referenced. javafx-swt.jar is delivered with the JDK, but is not loaded by default (or at least it should not be).
>>>>>>             
>>>>> Is there a way to find out? Do I have to provide additional options? Using jdk-9-ea109 the same command line did not result in javafx.swt being regarded as JDK internal.
>>>>>
>>>>>           
>>>>>>             
>>>>>>>> As for your second question, the expectation is that javafx.swt will be added as an automatic (and thus named) module in a layer, but that still needs to be tested. We currently do all of our own testing by adding it as an automatic module on the module path as follows:
>>>>>>>>
>>>>>>>> $ java --module-path $JAVA_HOME/lib/javafx-swt.jar --add-modules javafx.swt my.pkg.MyApp
>>>>>>>>                 
>>>>>>> I see. Is there a concrete schedule?
>>>>>>>               
>>>>>> If you mean is there a concrete schedule for the Eclipse folks to do the work to verify that javafx.swt can be loaded in a layer, I can't comment on that, since this work is outside the scope of the JDK. Perhaps Tom Schindl can respond?
>>>>>>             
>>>>> I thought the plan was to turn javafx.swt into an explicit module and not an (implicit) automatic one, and I was referring to when this was finalized. Seems I got that wrong.
>>>>>
>>>>>           
>>>>>> — Kevin
>>>>>>             
>>>>> Best Regards,
>>>>> Alexander
>>>>>
>>>>>           
>>>>>>>> — Kevin
>>>>>>>>                 
>>>>>>> Best Regards,
>>>>>>> Alexander
>>>>>>>
>>>>>>>               
>>>>>>>> Alexander Nyssen wrote:
>>>>>>>>                 
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code base and was astonished to see that all dependencies to javafx.embed.swt.* now seem to be regarded as JDK internal API. I assume this is just a temporal inconsistency. Therefore, let me ask when it is planned to transfer the javafx.swt module into a proper named JIGSAW module to resolve this. The Eclipse community relies on using the javafx.swt module in an OSGi environment (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), and it would certainly be good if conformance tests could be started as early as possible.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Alexander
>>>>>>>>>                   
>>>> -- 
>>>> Thomas Schindl, CTO
>>>> BestSolution.at EDV Systemhaus GmbH
>>>> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
>>>> http://www.bestsolution.at/
>>>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>>>>         
>
>