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.schi...@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 <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 >> >
