[9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9
Please review the following: https://bugs.openjdk.java.net/browse/JDK-8131888 http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). Details are in JBS. -- Kevin
Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9
> On May 25, 2016, at 3:38 PM, Kevin Rushforth
> wrote:
>
> Please review the following:
>
> https://bugs.openjdk.java.net/browse/JDK-8131888
> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/
>
> This adds support for the javafx.embed.swt package back into the JDK, which
> will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar
> (final location is TBD).
The approach to have javafx.swt be an automatic module that can access
org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I
wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar?
They both have the same module name “javafx.swt”.
I skimmed through the change. There are several System.err.println calls that
I assume are debugging code to be removed. e.g.
FXCanvas.java
247 System.err.println("FXCanvas class successfully initialized”);
294 System.err.println("FXCanvas: FX platform is
initlialized”);
PlatformImpl.java
308 System.err.println("FXCanvas: no permission to access
JavaFX internals");
309 ex.printStackTrace();
I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy
to see StackWalker be useful in this case. The check to compare the class name
with “javafx.embed.swt.FXCanvas” to derermine whether qualified exports should
be added. You can consider checking the caller's module name as a starter. I
know you are planning to look into the integrity check as a follows up.
ModuleHelper.java
57 // ignore
This deserves to be an InternalError. This is temporary until FX is
transitioned to be built with JDK 9.
Otherwise, look fine to me.
Mandy
Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9
Mandy,
Thanks for your feedback. Comments inline.
Mandy Chung wrote:
On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote:
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8131888
http://cr.openjdk.java.net/~kcr/8131888/webrev.00/
This adds support for the javafx.embed.swt package back into the JDK, which
will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar
(final location is TBD).
The approach to have javafx.swt be an automatic module that can access
org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I
wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar?
They both have the same module name “javafx.swt”.
Filenames with two dots are a little odd, so I went with the dash. It
doesn't much matter, though.
I skimmed through the change. There are several System.err.println calls that
I assume are debugging code to be removed. e.g.
FXCanvas.java
247 System.err.println("FXCanvas class successfully initialized”);
294 System.err.println("FXCanvas: FX platform is
initlialized”);
PlatformImpl.java
308 System.err.println("FXCanvas: no permission to access JavaFX
internals");
309 ex.printStackTrace();
Right. I noted this in the JBS evaluation and will remove all when I
post the final webrev.
I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy
to see StackWalker be useful in this case. The check to compare the class name
with “javafx.embed.swt.FXCanvas” to derermine whether qualified exports should
be added. You can consider checking the caller's module name as a starter. I
know you are planning to look into the integrity check as a follows up.
I had considered adding the check for the module name, but was concerned
about the OSGi case, as mentioned by Tom Schindl in the bug report, in
which they add the jar file via a custom classloader; the concern is
that there is no support in the JDK to make it an automatic module in
this case. I will file a follow-up issue to improve the integrity checking.
ModuleHelper.java
57 // ignore
This deserves to be an InternalError. This is temporary until FX is
transitioned to be built with JDK 9.
Actually, we can't do this yet, because we still build and test with JDK
9 build 109 which doesn't have support for the module system. Until we
upgrade to a JDK with the module system enabled we need this to be a
silent no-op or all of our tests will fail.
-- Kevin
Otherwise, look fine to me.
Mandy
Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9
If you add javafx-swt.jar to the custom classpath created by the OSGI
container it should work in the same way it does today when you add
jfxswt.jar.
Can you suggest an easy way that I can test this?
-- Kevin
Tom Schindl wrote:
Hi,
I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use
case for SWT useage.
The SWT jar is not on the application classpath so how should a module (named
or unnamed) find the SWT classes?
Tom
Von meinem iPhone gesendet
Am 26.05.2016 um 02:43 schrieb Mandy Chung :
On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote:
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8131888
http://cr.openjdk.java.net/~kcr/8131888/webrev.00/
This adds support for the javafx.embed.swt package back into the JDK, which
will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar
(final location is TBD).
The approach to have javafx.swt be an automatic module that can access
org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I
wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar?
They both have the same module name “javafx.swt”.
I skimmed through the change. There are several System.err.println calls that
I assume are debugging code to be removed. e.g.
FXCanvas.java
247 System.err.println("FXCanvas class successfully initialized”);
294 System.err.println("FXCanvas: FX platform is initlialized”);
PlatformImpl.java
308 System.err.println("FXCanvas: no permission to access JavaFX
internals");
309 ex.printStackTrace();
I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy
to see StackWalker be useful in this case. The check to compare the class name
with “javafx.embed.swt.FXCanvas” to derermine whether qualified exports should
be added. You can consider checking the caller's module name as a starter. I
know you are planning to look into the integrity check as a follows up.
ModuleHelper.java
57 // ignore
This deserves to be an InternalError. This is temporary until FX is
transitioned to be built with JDK 9.
Otherwise, look fine to me.
Mandy
Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9
Yes, I've tested it in both modes (with a simple HelloFXCanvas program)
-- as an automatic jar file and as just an ordinary jar on the classpath.
-- Kevin
Tom Schindl wrote:
Rereading the jira it take that back if javafx.swt can still be loaded as a
simple jar things will work
Tom
Von meinem iPhone gesendet
Am 26.05.2016 um 16:51 schrieb Tom Schindl :
Hi,
I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use
case for SWT useage.
The SWT jar is not on the application classpath so how should a module (named
or unnamed) find the SWT classes?
Tom
Von meinem iPhone gesendet
Am 26.05.2016 um 02:43 schrieb Mandy Chung :
On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote:
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8131888
http://cr.openjdk.java.net/~kcr/8131888/webrev.00/
This adds support for the javafx.embed.swt package back into the JDK, which
will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar
(final location is TBD).
The approach to have javafx.swt be an automatic module that can access
org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I
wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar?
They both have the same module name “javafx.swt”.
I skimmed through the change. There are several System.err.println calls that
I assume are debugging code to be removed. e.g.
FXCanvas.java
247 System.err.println("FXCanvas class successfully initialized”);
294 System.err.println("FXCanvas: FX platform is initlialized”);
PlatformImpl.java
308 System.err.println("FXCanvas: no permission to access JavaFX
internals");
309 ex.printStackTrace();
I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy
to see StackWalker be useful in this case. The check to compare the class name
with “javafx.embed.swt.FXCanvas” to derermine whether qualified exports should
be added. You can consider checking the caller's module name as a starter. I
know you are planning to look into the integrity check as a follows up.
ModuleHelper.java
57 // ignore
This deserves to be an InternalError. This is temporary until FX is
transitioned to be built with JDK 9.
Otherwise, look fine to me.
Mandy
Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9
> On May 26, 2016, at 8:38 AM, Kevin Rushforth
> wrote:
>
> Yes, I've tested it in both modes (with a simple HelloFXCanvas program) -- as
> an automatic jar file and as just an ordinary jar on the classpath.
an automatic module needs to be on modulepath.
For container-like environment, it can create a Layer to load javafx.swt with a
parent class loader that loads SWT classes - would that be feasible?
Mandy
>
> -- Kevin
>
>
> Tom Schindl wrote:
>> Rereading the jira it take that back if javafx.swt can still be loaded as a
>> simple jar things will work
>>
>> Tom
>>
>> Von meinem iPhone gesendet
>>
>>
>>
>>> Am 26.05.2016 um 16:51 schrieb Tom Schindl
>>> :
>>>
>>> Hi,
>>>
>>> I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%)
>>> use case for SWT useage.
>>>
>>> The SWT jar is not on the application classpath so how should a module
>>> (named or unnamed) find the SWT classes?
>>>
>>> Tom
>>>
>>> Von meinem iPhone gesendet
>>>
>>>
>>>
Am 26.05.2016 um 02:43 schrieb Mandy Chung
:
> On May 25, 2016, at 3:38 PM, Kevin Rushforth
> wrote:
>
> Please review the following:
>
>
> https://bugs.openjdk.java.net/browse/JDK-8131888
> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/
>
>
> This adds support for the javafx.embed.swt package back into the JDK,
> which will be delivered as an automatic module in
> $JAVA_HOME/lib/javafx-swt.jar (final location is TBD).
>
>
The approach to have javafx.swt be an automatic module that can access
org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable.
I wonder what the JAR file should be named - javafx.swt.jar or
javafx-swt.jar? They both have the same module name “javafx.swt”.
I skimmed through the change. There are several System.err.println calls
that I assume are debugging code to be removed. e.g.
FXCanvas.java
247 System.err.println("FXCanvas class successfully initialized”);
294 System.err.println("FXCanvas: FX platform is
initlialized”);
PlatformImpl.java
308 System.err.println("FXCanvas: no permission to access
JavaFX internals");
309 ex.printStackTrace();
I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods.
Happy to see StackWalker be useful in this case. The check to compare the
class name with “javafx.embed.swt.FXCanvas” to derermine whether qualified
exports should be added. You can consider checking the caller's module
name as a starter. I know you are planning to look into the integrity
check as a follows up.
ModuleHelper.java
57 // ignore
This deserves to be an InternalError. This is temporary until FX is
transitioned to be built with JDK 9.
Otherwise, look fine to me.
Mandy
>>
>>
>>
Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9
I'll prepare a simple osgi swt test app
Tom
Von meinem iPhone gesendet
> Am 26.05.2016 um 17:38 schrieb Kevin Rushforth :
>
> Yes, I've tested it in both modes (with a simple HelloFXCanvas program) -- as
> an automatic jar file and as just an ordinary jar on the classpath.
>
> -- Kevin
>
>
> Tom Schindl wrote:
>>
>> Rereading the jira it take that back if javafx.swt can still be loaded as a
>> simple jar things will work
>>
>> Tom
>>
>> Von meinem iPhone gesendet
>>
>>
Am 26.05.2016 um 16:51 schrieb Tom Schindl :
Hi,
I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%)
use case for SWT useage.
The SWT jar is not on the application classpath so how should a module
(named or unnamed) find the SWT classes?
Tom
Von meinem iPhone gesendet
> Am 26.05.2016 um 02:43 schrieb Mandy Chung :
>
>
>
>
> On May 25, 2016, at 3:38 PM, Kevin Rushforth
> wrote:
>
> Please review the following:
>
> https://bugs.openjdk.java.net/browse/JDK-8131888
> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/
>
> This adds support for the javafx.embed.swt package back into the JDK,
> which will be delivered as an automatic module in
> $JAVA_HOME/lib/javafx-swt.jar (final location is TBD).
>
The approach to have javafx.swt be an automatic module that can access
org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable.
I wonder what the JAR file should be named - javafx.swt.jar or
javafx-swt.jar? They both have the same module name “javafx.swt”.
I skimmed through the change. There are several System.err.println calls
that I assume are debugging code to be removed. e.g.
FXCanvas.java
247 System.err.println("FXCanvas class successfully initialized”);
294 System.err.println("FXCanvas: FX platform is
initlialized”);
PlatformImpl.java
308 System.err.println("FXCanvas: no permission to access
JavaFX internals");
309 ex.printStackTrace();
I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods.
Happy to see StackWalker be useful in this case. The check to compare the
class name with “javafx.embed.swt.FXCanvas” to derermine whether qualified
exports should be added. You can consider checking the caller's module
name as a starter. I know you are planning to look into the integrity
check as a follows up.
ModuleHelper.java
57 // ignore
This deserves to be an InternalError. This is temporary until FX is
transitioned to be built with JDK 9.
Otherwise, look fine to me.
Mandy
Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9
Hi,
I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use
case for SWT useage.
The SWT jar is not on the application classpath so how should a module (named
or unnamed) find the SWT classes?
Tom
Von meinem iPhone gesendet
> Am 26.05.2016 um 02:43 schrieb Mandy Chung :
>
>
>
>> On May 25, 2016, at 3:38 PM, Kevin Rushforth
>> wrote:
>>
>> Please review the following:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8131888
>> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/
>>
>> This adds support for the javafx.embed.swt package back into the JDK, which
>> will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar
>> (final location is TBD).
>
> The approach to have javafx.swt be an automatic module that can access
> org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I
> wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar?
> They both have the same module name “javafx.swt”.
>
> I skimmed through the change. There are several System.err.println calls
> that I assume are debugging code to be removed. e.g.
>
> FXCanvas.java
> 247 System.err.println("FXCanvas class successfully initialized”);
> 294 System.err.println("FXCanvas: FX platform is
> initlialized”);
>
> PlatformImpl.java
> 308 System.err.println("FXCanvas: no permission to access
> JavaFX internals");
> 309 ex.printStackTrace();
>
> I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods.
> Happy to see StackWalker be useful in this case. The check to compare the
> class name with “javafx.embed.swt.FXCanvas” to derermine whether qualified
> exports should be added. You can consider checking the caller's module name
> as a starter. I know you are planning to look into the integrity check as a
> follows up.
>
> ModuleHelper.java
> 57 // ignore
>
> This deserves to be an InternalError. This is temporary until FX is
> transitioned to be built with JDK 9.
>
> Otherwise, look fine to me.
> Mandy
Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9
Rereading the jira it take that back if javafx.swt can still be loaded as a
simple jar things will work
Tom
Von meinem iPhone gesendet
> Am 26.05.2016 um 16:51 schrieb Tom Schindl :
>
> Hi,
>
> I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use
> case for SWT useage.
>
> The SWT jar is not on the application classpath so how should a module (named
> or unnamed) find the SWT classes?
>
> Tom
>
> Von meinem iPhone gesendet
>
>> Am 26.05.2016 um 02:43 schrieb Mandy Chung :
>>
>>
>>
>>> On May 25, 2016, at 3:38 PM, Kevin Rushforth
>>> wrote:
>>>
>>> Please review the following:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8131888
>>> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/
>>>
>>> This adds support for the javafx.embed.swt package back into the JDK, which
>>> will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar
>>> (final location is TBD).
>>
>> The approach to have javafx.swt be an automatic module that can access
>> org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I
>> wonder what the JAR file should be named - javafx.swt.jar or
>> javafx-swt.jar? They both have the same module name “javafx.swt”.
>>
>> I skimmed through the change. There are several System.err.println calls
>> that I assume are debugging code to be removed. e.g.
>>
>> FXCanvas.java
>> 247 System.err.println("FXCanvas class successfully initialized”);
>> 294 System.err.println("FXCanvas: FX platform is
>> initlialized”);
>>
>> PlatformImpl.java
>> 308 System.err.println("FXCanvas: no permission to access
>> JavaFX internals");
>> 309 ex.printStackTrace();
>>
>> I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods.
>> Happy to see StackWalker be useful in this case. The check to compare the
>> class name with “javafx.embed.swt.FXCanvas” to derermine whether qualified
>> exports should be added. You can consider checking the caller's module name
>> as a starter. I know you are planning to look into the integrity check as a
>> follows up.
>>
>> ModuleHelper.java
>> 57 // ignore
>>
>> This deserves to be an InternalError. This is temporary until FX is
>> transitioned to be built with JDK 9.
>>
>> Otherwise, look fine to me.
>> Mandy
>
Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9
Do you have an example how to construct such a Layer?
Tom
Von meinem iPhone gesendet
> Am 26.05.2016 um 17:47 schrieb Mandy Chung :
>
>
>> On May 26, 2016, at 8:38 AM, Kevin Rushforth
>> wrote:
>>
>> Yes, I've tested it in both modes (with a simple HelloFXCanvas program) --
>> as an automatic jar file and as just an ordinary jar on the classpath.
>
> an automatic module needs to be on modulepath.
>
> For container-like environment, it can create a Layer to load javafx.swt with
> a parent class loader that loads SWT classes - would that be feasible?
>
> Mandy
>
>>
>> -- Kevin
>>
>>
>> Tom Schindl wrote:
>>> Rereading the jira it take that back if javafx.swt can still be loaded as a
>>> simple jar things will work
>>>
>>> Tom
>>>
>>> Von meinem iPhone gesendet
>>>
>>>
>>>
Am 26.05.2016 um 16:51 schrieb Tom Schindl
:
Hi,
I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%)
use case for SWT useage.
The SWT jar is not on the application classpath so how should a module
(named or unnamed) find the SWT classes?
Tom
Von meinem iPhone gesendet
> Am 26.05.2016 um 02:43 schrieb Mandy Chung
> :
>
>
>
>
>
>> On May 25, 2016, at 3:38 PM, Kevin Rushforth
>> wrote:
>>
>> Please review the following:
>>
>>
>> https://bugs.openjdk.java.net/browse/JDK-8131888
>> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/
>>
>>
>> This adds support for the javafx.embed.swt package back into the JDK,
>> which will be delivered as an automatic module in
>> $JAVA_HOME/lib/javafx-swt.jar (final location is TBD).
> The approach to have javafx.swt be an automatic module that can access
> org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable.
> I wonder what the JAR file should be named - javafx.swt.jar or
> javafx-swt.jar? They both have the same module name “javafx.swt”.
>
> I skimmed through the change. There are several System.err.println calls
> that I assume are debugging code to be removed. e.g.
>
> FXCanvas.java
> 247 System.err.println("FXCanvas class successfully initialized”);
> 294 System.err.println("FXCanvas: FX platform is
> initlialized”);
>
> PlatformImpl.java
> 308 System.err.println("FXCanvas: no permission to access
> JavaFX internals");
> 309 ex.printStackTrace();
>
> I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods.
> Happy to see StackWalker be useful in this case. The check to compare
> the class name with “javafx.embed.swt.FXCanvas” to derermine whether
> qualified exports should be added. You can consider checking the
> caller's module name as a starter. I know you are planning to look into
> the integrity check as a follows up.
>
> ModuleHelper.java
> 57 // ignore
>
> This deserves to be an InternalError. This is temporary until FX is
> transitioned to be built with JDK 9.
>
> Otherwise, look fine to me.
> Mandy
>
Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9
On 26/05/2016 16:38, Kevin Rushforth wrote: Yes, I've tested it in both modes (with a simple HelloFXCanvas program) -- as an automatic jar file and as just an ordinary jar on the classpath. Just curious, if there are qualified exports to javafx.swt then how it does when on the class path? -Alan
Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9
Alan Bateman wrote: On 26/05/2016 16:38, Kevin Rushforth wrote: Yes, I've tested it in both modes (with a simple HelloFXCanvas program) -- as an automatic jar file and as just an ordinary jar on the classpath. Just curious, if there are qualified exports to javafx.swt then how it does when on the class path? The qualified exports are done using reflection to the calling module that contains the javafx.embed.swt.FXCanvas class, irrespective of the name of the module (so it works even when the javafx.embed.swt package is in the unnamed module). I plan to file a follow-on bug to tighten the integrity checks, which may or may not include requiring it to be in a module named "javafx.swt", depending on whether all of the use cases can be done with javafx-swt.jar being loaded in a named module (e.g., Mandy's recommendation of using the Layer API). -- Kevin
Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9
On 27/05/2016 13:47, Kevin Rushforth wrote: The qualified exports are done using reflection to the calling module that contains the javafx.embed.swt.FXCanvas class, irrespective of the name of the module (so it works even when the javafx.embed.swt package is in the unnamed module). I plan to file a follow-on bug to tighten the integrity checks, which may or may not include requiring it to be in a module named "javafx.swt", depending on whether all of the use cases can be done with javafx-swt.jar being loaded in a named module (e.g., Mandy's recommendation of using the Layer API). Okay and using addExports is really the only way this will work when javafx.swt is a child layer. As regards the mixing of code in named modules and unnamed modules then it should work fine. javafx.swt will read all modules in the boot layer. Code this module will also link to SWT types and for that to work then they must be visible by means of its class loader. The simplest is to just specify that loader as the parent class loader when creating the child layer. -Alan
Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9
Thanks for confirming. So it sounds like we have a workable plan. -- Kevin Alan Bateman wrote: On 27/05/2016 13:47, Kevin Rushforth wrote: The qualified exports are done using reflection to the calling module that contains the javafx.embed.swt.FXCanvas class, irrespective of the name of the module (so it works even when the javafx.embed.swt package is in the unnamed module). I plan to file a follow-on bug to tighten the integrity checks, which may or may not include requiring it to be in a module named "javafx.swt", depending on whether all of the use cases can be done with javafx-swt.jar being loaded in a named module (e.g., Mandy's recommendation of using the Layer API). Okay and using addExports is really the only way this will work when javafx.swt is a child layer. As regards the mixing of code in named modules and unnamed modules then it should work fine. javafx.swt will read all modules in the boot layer. Code this module will also link to SWT types and for that to work then they must be visible by means of its class loader. The simplest is to just specify that loader as the parent class loader when creating the child layer. -Alan
Re: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9
> On May 27, 2016, at 1:30 AM, Tom Schindl wrote:
>
> Do you have an example how to construct such a Layer?
// path is the path to javafx-swt.jar
ModuleFinder finder = ModuleFinder.of(path);
Configuration cf = Layer.boot()
.configuration()
.resolveRequires(finder, ModuleFinder.of(), Set.of("javafx.swt"));
// “parent” is the class loader to which SWT types are visible
Layer layer = Layer.boot().defineModulesWithOneLoader(cf, parent);
// the class loader defining javafx.swt module
ClassLoader loader = layer.findLoader("javafx.swt”);
[1] will show more examples of Layer.
Mandy
[1]
http://hg.openjdk.java.net/jdk9/dev/jdk/file/df35a805b405/test/java/lang/reflect/Layer/LayerAndLoadersTest.java
