Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

[Sundararajan Athijegannathan]

But, in addition to providing service, jdk.scripting.nashorn module also 
"exports" nashorn specific APIs in jdk.nashorn.api.* packages.


-Sundar

On 11/23/2015 9:10 PM, Alan Bateman wrote:



On 23/11/2015 15:27, Attila Szegedi wrote:

Folks,

I integrated the changes Mandy suggested; please review these (build 
related) changes:
jdk9 top level: 

jdk9/jdk: 



For the sake of completeness, the jdk/nashorn changes are here: 
 but they 
have already been reviewed by Hannes and Sundar; only the above two 
(jdk9 and jdk9/jdk) have been modified compared to the original 
review request.


Sundar was kind enough to verify that JDK9 builds fine with these 
changes.



The jdk repo looks okay (just had to change your link to find it :-)

In the top-level repo then you've moved jdk.scripting.nashorn from 
PROVIDER_MODULES to MAIN_MODULES. The reason that we've had it in 
PROVIDER_MODULES is because we treat it as a service provider module 
(it provides an implementation of javax.script.ScriptEngineFactory).


-Alan.

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

[Mandy Chung]

> On Nov 23, 2015, at 7:40 AM, Alan Bateman  wrote:
> 
> 
> 
> On 23/11/2015 15:27, Attila Szegedi wrote:
>> Folks,
>> 
>> I integrated the changes Mandy suggested; please review these (build 
>> related) changes:
>> jdk9 top level: 
>> 
>> jdk9/jdk: 
>> 
>> 
>> For the sake of completeness, the jdk/nashorn changes are here: 
>>  but they have 
>> already been reviewed by Hannes and Sundar; only the above two (jdk9 and 
>> jdk9/jdk) have been modified compared to the original review request.
>> 
>> Sundar was kind enough to verify that JDK9 builds fine with these changes.
>> 
> The jdk repo looks okay (just had to change your link to find it :-)
> 
> In the top-level repo then you've moved jdk.scripting.nashorn from 
> PROVIDER_MODULES to MAIN_MODULES. The reason that we've had it in 
> PROVIDER_MODULES is because we treat it as a service provider module (it 
> provides an implementation of javax.script.ScriptEngineFactory).

jdk.scripting.nashorn now exports two API packages.  It is no longer a sole 
service provider and so I asked Attila to move it MAIN_MODULE.

Mandy

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

[Alan Bateman]

On 23/11/2015 16:07, Attila Szegedi wrote:

:
Whichever is the stronger criteria for deciding whether to place it in MAIN or 
PROVIDER is fine with me. Intuitively “provider” seems like a weaker category 
(exposes a service provider but doesn’t have its own API), so (without knowing 
the particulars of the use of these *_MODULES variables) it seems to me Mandy’s 
suggestion is correct to reclassify Nashorn into a MAIN module.

We need to do a bit of clean-up in Images.gmk to make things clearer as 
this MAIN vs. PROVIDER topic has caused confusion on a few cases. If we 
can keep the lists separate to the list of modules for the compact 
profile builds then there is no reason why they can't be combined as 
JRE_MODULES.


In this case then jdk.scripting.nashorn.shell is already listed in 
MAIN_MODULES so this will ensure than Nashorn is linked into any 
run-time image that has the the jjs tool/shell. It doesn't matter if 
jdk.scripting.nashorn is listed or not.


-Alan.

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

[Alan Bateman]

On 23/11/2015 15:43, Sundararajan Athijegannathan wrote:
But, in addition to providing service, jdk.scripting.nashorn module 
also "exports" nashorn specific APIs in jdk.nashorn.api.* packages.

Sure, it could go in either but we mostly treat it as a service provider.

-Alan.

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

[Mandy Chung]

> On Nov 23, 2015, at 8:42 AM, Alan Bateman  wrote:
> 
> We need to do a bit of clean-up in Images.gmk to make things clearer as this 
> MAIN vs. PROVIDER topic has caused confusion on a few cases. If we can keep 
> the lists separate to the list of modules for the compact profile builds then 
> there is no reason why they can't be combined as JRE_MODULES.

Agree and we should clean that up to remove the confusion.

Mandy

[9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

[Siba Sahoo]

Hi,

 

Please help me with your review of this test for JBS: 
https://bugs.openjdk.java.net/browse/JDK-8130360, 

 

Webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.01/

 

Description

Tests to verify 3rd party security providers if they are in signed/unsigned 
modular JARs. The test code checks the modular behavior with different 
combination of separate client & security provider, when available as 
modular(signed/unsigned) jar. It address total  of 72 test cases with the 
following criteria:

 

(Signed/Unsigned Jar) X (ClassLoader/ServiceLoader) X (combination of 
EXPLICIT/AUTO/UNAMED modules) X (With/Without Service descriptor) 

 

Thanks,

Siba

 

RE: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

[Siba Sahoo]

+HYPERLINK "mailto:security-...@openjdk.java.net"security-...@openjdk.java.net

 

From: Siba Sahoo 
Sent: Monday, November 23, 2015 4:56 PM
To: jigsaw-dev@openjdk.java.net; jdk-security-dev_ww_grp; Sean Mullan
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if 
they are in signed/unsigned modular JARs

 

Hi,

 

Please help me with your review of this test for JBS: 
https://bugs.openjdk.java.net/browse/JDK-8130360, 

 

Webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.01/

 

Description

Tests to verify 3rd party security providers if they are in signed/unsigned 
modular JARs. The test code checks the modular behavior with different 
combination of separate client & security provider, when available as 
modular(signed/unsigned) jar. It address total  of 72 test cases with the 
following criteria:

 

(Signed/Unsigned Jar) X (ClassLoader/ServiceLoader) X (combination of 
EXPLICIT/AUTO/UNAMED modules) X (With/Without Service descriptor) 

 

Thanks,

Siba

 

Re: RFR: 8139430

[Mandy Chung]

Hi Shura,

I have pushed the changeset to jdk9/dev.

Mandy

> On Nov 19, 2015, at 8:40 AM, Alexandre (Shura) Iline 
>  wrote:
> 
> Yes, sorry.
> 
> Since the methods do not have any work to complete before interrupting and 
> also methods are not used anywhere currently, I assume re-throwing the 
> InterruptedException is a better choice.
> 
> http://cr.openjdk.java.net/~shurailine/8139430/webrev.07/test/lib/testlibrary/jdk/testlibrary/management/ThreadMXBeanTool.java.html
> 
> Shura
> 
>> On Nov 16, 2015, at 8:33 PM, Mandy Chung  wrote:
>> 
>> 
>>> On Nov 16, 2015, at 5:38 AM, Alan Bateman  wrote:
>>> 
>>> 
>>> 
>>> On 16/11/2015 13:01, Alexandre (Shura) Iline wrote:
 V6:
 http://cr.openjdk.java.net/~shurailine/8139430/webrev.06/
 
 
>>> This looks okay to me. For completeness then I assume the 
>>> THreadMXBeanTool.waitUntilXXX methods should re-assert the interrupt status 
>>> if interrupted when waiting.
>> 
>> +1
>> 
>> Mandy
>> 
> 

Re: A way to opt out of access restrictions on non-exported members.

[Alan Snyder]

> On Nov 23, 2015, at 4:24 PM, Alex Buckley  wrote:
> 
> I know there is considerable effort going into replacement public APIs for 
> JavaFX -- see http://openjdk.java.net/jeps/253 
>  from May and the openjfx-dev thread 
> "Understanding the com.sun.* APIs being (ab)used by the community" from June 
> -- you could inquire about equivalents on swing-dev.

Yes, I have already proposed some and some are under development. I have not 
proposed low level ones yet.

  Alan

Re: A way to opt out of access restrictions on non-exported members.

[Alex Buckley]

On 11/23/2015 9:58 AM, Alan Snyder wrote:

My use case is a platform specific Swing look and feel. To work, it
needs access to platform specific features of the AWT. I’m trying not
to be pessimistic or cynical, but I cannot assume that Oracle/OpenJDK
will be motivated to create a public API for all of the platform
specific features that I need, or if they do, that the API will be
available in a timely manner. I understand that my library will have
dependencies on specific JDK versions as it does on specific platform
versions.


I know there is considerable effort going into replacement public APIs 
for JavaFX -- see http://openjdk.java.net/jeps/253 from May and the 
openjfx-dev thread "Understanding the com.sun.* APIs being (ab)used by 
the community" from June -- you could inquire about equivalents on 
swing-dev.


Alex


I was unpleasantly surprised to learn (via the recent Java One talks)
that the module encapsulation rules apply to reflection, as I had
understood that they did not.

Using command line arguments as an escape mechanism is not a good fit
for this use. The main reason is that it places a burden on all users
of the library, both direct and indirect. Every application in which
this library is used must define the appropriate command line
arguments. The other reason is that the command line argument
solution is too broad. Using reflection, each specific need to
penetrate encapsulation is identified. Using the command line
argument, entire packages are opened up.

Which brings me to a question... How is native code access to classes
and methods via JNI affected by module encapsulation?

Alan

Re: RFR 8135972: Implement new tests for native libjimage library

[Sergei Pikalev]

Hi All,

http://cr.openjdk.java.net/~jlaskey/8135972/webrev.01/index.html

There are a minimal set of passing cleanly tests which does not explore
bad values touching memory addresses.

Please review.

Thanks,
Sergi

On 13.11.2015 17:12, Alan Bateman wrote:

On 13/11/2015 13:50, Sergei Pikalev wrote:


Hello,

This is the code with new tests for libjimage native library.

A webrev with the tests is here:

http://cr.openjdk.java.net/~jlaskey/8135972/webrev.00/index.html


Are there tests passing cleanly on all platforms? At least some of 
them seems to be passing bad values to native methods that take memory 
addresses.


Are the tests tied to changes in jigsaw/jake or can these tests go 
into jdk9/dev to follow the jimage changes that are also going in via 
that route?


-Alan

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

[Hannes Wallnoefer]

+1 for the Nashorn/Dynalink changes.

The top level changes look good to me but I'd prefer to leave reviews to 
those who are more familiar with the build/modules infrastructure.


Hannes

Am 2015-11-20 um 00:15 schrieb Attila Szegedi:

Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for 
. This is basically the implementation 
step for integrating JEP 276. This changeset will introduce a new public API that has CCC 
approval (request 8075866), and is also the implementation step of JEP 276 which is now 
targeted for 9 and thus can be integrated.

The changes in this changeset fall into several categories:
- renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with 
ripple effects in Nashorn classes that import from these packages
- changes to modules.xml and some build files to accommodate a new public 
module and a dependency of Nashorn on it
- new tests

  I’m sending this webrev to several lists with the following rationales:
- nashorn-dev as the primary users and expected reviewers (also, the Dynalink 
module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of newly added test 
code was contributed by Sundar.
- jigsaw-dev because of modules.xml changes
- jdk9-dev for build changes (build file changes were graciously contributed by 
Erik Joelsson and Sundar)
- core-libs-dev since that’s the designated JEP 276 discussion list.

Nashorn changes: 
top-level jdk9 changes: 


Thanks,
   Attila.

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

[Alan Bateman]

On 23/11/2015 15:27, Attila Szegedi wrote:

Folks,

I integrated the changes Mandy suggested; please review these (build related) 
changes:
jdk9 top level: 

jdk9/jdk: 


For the sake of completeness, the jdk/nashorn changes are here: 
 but they have already 
been reviewed by Hannes and Sundar; only the above two (jdk9 and jdk9/jdk) have been 
modified compared to the original review request.

Sundar was kind enough to verify that JDK9 builds fine with these changes.


The jdk repo looks okay (just had to change your link to find it :-)

In the top-level repo then you've moved jdk.scripting.nashorn from 
PROVIDER_MODULES to MAIN_MODULES. The reason that we've had it in 
PROVIDER_MODULES is because we treat it as a service provider module (it 
provides an implementation of javax.script.ScriptEngineFactory).


-Alan.

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

[Attila Szegedi]

> On Nov 23, 2015, at 4:40 PM, Alan Bateman  wrote:
> 
> 
> 
> On 23/11/2015 15:27, Attila Szegedi wrote:
>> Folks,
>> 
>> I integrated the changes Mandy suggested; please review these (build 
>> related) changes:
>> jdk9 top level: 
>> 
>> jdk9/jdk: 
>> 
>> 
>> For the sake of completeness, the jdk/nashorn changes are here: 
>>  but they have 
>> already been reviewed by Hannes and Sundar; only the above two (jdk9 and 
>> jdk9/jdk) have been modified compared to the original review request.
>> 
>> Sundar was kind enough to verify that JDK9 builds fine with these changes.
>> 
> The jdk repo looks okay (just had to change your link to find it :-)

D’oh. I was doublechecking those links few times and still managed to bungle 
it… thanks for figuring it out.
> 
> In the top-level repo then you've moved jdk.scripting.nashorn from 
> PROVIDER_MODULES to MAIN_MODULES. The reason that we've had it in 
> PROVIDER_MODULES is because we treat it as a service provider module (it 
> provides an implementation of javax.script.ScriptEngineFactory).

Whichever is the stronger criteria for deciding whether to place it in MAIN or 
PROVIDER is fine with me. Intuitively “provider” seems like a weaker category 
(exposes a service provider but doesn’t have its own API), so (without knowing 
the particulars of the use of these *_MODULES variables) it seems to me Mandy’s 
suggestion is correct to reclassify Nashorn into a MAIN module.

Attila.

> 
> -Alan.
> 

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

[Attila Szegedi]

Folks,

I integrated the changes Mandy suggested; please review these (build related) 
changes:
jdk9 top level: 
 
jdk9/jdk: 
 

For the sake of completeness, the jdk/nashorn changes are here: 
 but they have already 
been reviewed by Hannes and Sundar; only the above two (jdk9 and jdk9/jdk) have 
been modified compared to the original review request.

Sundar was kind enough to verify that JDK9 builds fine with these changes.

Thanks,
  Attila.

> On Nov 20, 2015, at 4:41 PM, Attila Szegedi  wrote:
> 
> Thanks for pointing out these, Mandy; I will make the changes you suggested.
> 
> Attila.
> 
>> On Nov 20, 2015, at 6:10 AM, Mandy Chung  wrote:
>> 
>> jdk.scripting.nashorn is loaded by the extension class loader.  Is 
>> jdk.dynalink expected to be loaded by the ext. class loader?
>> 
>> You need to edit this file to include the new module:
>>  jdk/make/src/classes/build/tools/module/ext.modules
>> 
>> This is an interim file to map modules to class loader and we will fix it 
>> when the changeset propagates to jake.
>> Mandy
>> 
>>> On Nov 19, 2015, at 7:00 PM, Mandy Chung  wrote:
>>> 
>>> I reviewed the top repo change.
>>> 
>>> modules.xml looks fine.
>>> 
>>> jdk.dynalink  should be in MAIN_MODULES since it has exported APIs.  
>>> jdk.scripting.nashorn should be moved too.  They are not sole service 
>>> providers.  Since you are on this file, can you move jdk.scripting.nashorn 
>>> to MAIN_MODULES as well?
>>> 
>>> Mandy
>>> 
 On Nov 19, 2015, at 3:15 PM, Attila Szegedi  wrote:
 
 Please review JDK-8141338 "Move jdk.internal.dynalink package to 
 jdk.dynalink" for . This 
 is basically the implementation step for integrating JEP 276. This 
 changeset will introduce a new public API that has CCC approval (request 
 8075866), and is also the implementation step of JEP 276 which is now 
 targeted for 9 and thus can be integrated.
 
 The changes in this changeset fall into several categories:
 - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, 
 with ripple effects in Nashorn classes that import from these packages
 - changes to modules.xml and some build files to accommodate a new public 
 module and a dependency of Nashorn on it
 - new tests
 
 I’m sending this webrev to several lists with the following rationales:
 - nashorn-dev as the primary users and expected reviewers (also, the 
 Dynalink module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of 
 newly added test code was contributed by Sundar.
 - jigsaw-dev because of modules.xml changes
 - jdk9-dev for build changes (build file changes were graciously 
 contributed by Erik Joelsson and Sundar)
 - core-libs-dev since that’s the designated JEP 276 discussion list.
 
 Nashorn changes:  
 top-level jdk9 changes: 
 
 
 Thanks,
 Attila.
 
>>> 
>> 
> 

Re: A way to opt out of access restrictions on non-exported members.

[Alan Snyder]

> There are rather a lot of libraries out there that access private
> members via reflection. I posit that almost all such libraries break
> without an easy way to fix the problem, if there is no way to use
> reflection to access non-exported members.

I agree with Reinier that there are situations where it makes sense to bypass 
module encapsulation and the existing access rules. Encapsulation is a good 
thing, but unless it is needed for security, Java should not be totally rigid 
about it.

My use case is a platform specific Swing look and feel. To work, it needs 
access to platform specific features of the AWT. I’m trying not to be 
pessimistic or cynical, but I cannot assume that Oracle/OpenJDK will be 
motivated to create a public API for all of the platform specific features that 
I need, or if they do, that the API will be available in a timely manner. I 
understand that my library will have dependencies on specific JDK versions as 
it does on specific platform versions.

I was unpleasantly surprised to learn (via the recent Java One talks) that the 
module encapsulation rules apply to reflection, as I had understood that they 
did not.

Using command line arguments as an escape mechanism is not a good fit for this 
use. The main reason is that it places a burden on all users of the library, 
both direct and indirect. Every application in which this library is used must 
define the appropriate command line arguments. The other reason is that the 
command line argument solution is too broad. Using reflection, each specific 
need to penetrate encapsulation is identified. Using the command line argument, 
entire packages are opened up.

Which brings me to a question... How is native code access to classes and 
methods via JNI affected by module encapsulation?

  Alan