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 <alexan...@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.schi...@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.rushfo...@oracle.com>: >>>> >>>> >>>> >>>> Alexander Nyssen wrote: >>>>> Hi Kevin, >>>>> >>>>>> Am 13.09.2016 um 15:42 schrieb Kevin Rushforth >>>>>> <kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@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 >
