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

[Alexander Nyssen]

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