JEP-282: JLink two modules exporting the same package name

[Karl Heinz Marbaise]

Hi,

i have a question concerning the jlink command in JDK 9..(EA +138 build)

I have created two modules lets call them module A and module B 
(module-info.java):


module A {
   requires java.base;
   exports com.single.package;
}

module B {
   requires java.base;
   exports com.single.package;
}

both export the same package: com.single.package

The question is: Shouldn't the jlink command fail in such cases cause 
both modules export the same package ?


Otherwise it would mean to fail at the time of starting the generated 
JVM image which I think is too late...


WDYT ?


Kind regards
Karl Heinz Marbaise

RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

[Sundararajan Athijegannathan]

Bug: https://bugs.openjdk.java.net/browse/JDK-8167614

jdk webrev: http://cr.openjdk.java.net/~sundar/8167614/jdk/webrev.00/

nashorn webrev:
http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.00/

Thanks,

-Sundar

Re: RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

[Sundararajan Athijegannathan]

Dynalink normally uses unreflect with publicLookup to get method handles
for j.l.reflect.Method objects (found reflectively). But, publicLookup
can not be used to unreflect caller sensitive methods. So, dynalink uses
specific Lookup object from the callsite - for example, lookup of the
Nashorn script (generated) class. But, script module has to have
read-edge the module of the CallerSensitive method's class - or else
that unreflect will fail.

Dynalink used to automatically add those necessary add edges. With the
current change, nashorn adds necessary read edges. CallerSensitive
methods are found only in java.base, java.logging, java.sql and
java.sql.rowset modules - the first two are always present [in nashorn's
compact1 dependency world]. The later two are checked for presence and
read-edges are added conditionally (see ScriptLoader.java changes).

Yes, I need boot layer modules only and I'll change that.

-Sundar

On 10/12/2016 8:51 PM, Alan Bateman wrote:
> On 12/10/2016 16:11, Sundararajan Athijegannathan wrote:
>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167614
>>
>> jdk webrev: http://cr.openjdk.java.net/~sundar/8167614/jdk/webrev.00/
>>
>> nashorn webrev:
>> http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.00/
>>
> In jdk/nashorn/internal/runtime/Context.java then it checks if the
> java.sql and java.sql.rowset are observable. This does not mean they
> are in the boot layer, I think you want
> Layer.boot().findModule("java.sql").ifPresent(...). However, the this
> code in Nashorn makes me wonder if this is actually needed or why
> these two are special cased.
>
> -Alan

Re: RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

[Alan Bateman]

On 12/10/2016 16:11, Sundararajan Athijegannathan wrote:


Bug: https://bugs.openjdk.java.net/browse/JDK-8167614

jdk webrev: http://cr.openjdk.java.net/~sundar/8167614/jdk/webrev.00/

nashorn webrev:
http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.00/

In jdk/nashorn/internal/runtime/Context.java then it checks if the 
java.sql and java.sql.rowset are observable. This does not mean they are 
in the boot layer, I think you want 
Layer.boot().findModule("java.sql").ifPresent(...). However, the this 
code in Nashorn makes me wonder if this is actually needed or why these 
two are special cased.


-Alan

Re: RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

[Jim Laskey (Oracle)]

+1

> On Oct 12, 2016, at 12:11 PM, Sundararajan Athijegannathan 
>  wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8167614
> 
> jdk webrev: http://cr.openjdk.java.net/~sundar/8167614/jdk/webrev.00/
> 
> nashorn webrev:
> http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.00/
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

[Sundararajan Athijegannathan]

Updated nashorn webrev:
http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.01/

Changed to use Layer.boot().findModule.

Thanks

-Sundar


On 10/12/2016 9:42 PM, Alan Bateman wrote:
> On 12/10/2016 16:33, Sundararajan Athijegannathan wrote:
>
>> :
>>
>> Dynalink used to automatically add those necessary add edges. With the
>> current change, nashorn adds necessary read edges. CallerSensitive
>> methods are found only in java.base, java.logging, java.sql and
>> java.sql.rowset modules - the first two are always present [in nashorn's
>> compact1 dependency world]. The later two are checked for presence and
>> read-edges are added conditionally (see ScriptLoader.java changes).
> JDK-8154346 tracks fixing java.sql.DriverManager, there are
> compatibility concerns to changing it but it is being looked at.
>
> I'm not familiar with the issue in the java.sql.rowset module but it
> may be that the security checks in SerialJavaObject::getFields can be
> re-visited (I don't know all the history on that).
>
>
>>
>> Yes, I need boot layer modules only and I'll change that.
>>
> Thanks.
>
> -Alan.

Re: JEP-282: JLink two modules exporting the same package name

[Alex Buckley]

In general, there is no problem with modules in the image or on the 
modulepath that contain and export the same package. The problem comes 
when a single module requires two other modules which both contain and 
export the same package. There is no such single module in the image 
you're creating -- your modules A and B are independent.


Alex

On 10/12/2016 11:17 AM, Karl Heinz Marbaise wrote:

Hi,

i have a question concerning the jlink command in JDK 9..(EA +138 build)

I have created two modules lets call them module A and module B
(module-info.java):

module A {
requires java.base;
exports com.single.package;
}

module B {
requires java.base;
exports com.single.package;
}

both export the same package: com.single.package

The question is: Shouldn't the jlink command fail in such cases cause
both modules export the same package ?

Otherwise it would mean to fail at the time of starting the generated
JVM image which I think is too late...

WDYT ?


Kind regards
Karl Heinz Marbaise

Re: JEP-282: JLink two modules exporting the same package name

[Alan Bateman]

On 12/10/2016 19:17, Karl Heinz Marbaise wrote:


Hi,

i have a question concerning the jlink command in JDK 9..(EA +138 build)

I have created two modules lets call them module A and module B 
(module-info.java):


module A {
   requires java.base;
   exports com.single.package;
}

module B {
   requires java.base;
   exports com.single.package;
}

both export the same package: com.single.package

The question is: Shouldn't the jlink command fail in such cases cause 
both modules export the same package ?


Otherwise it would mean to fail at the time of starting the generated 
JVM image which I think is too late...
You can resolve independent modules A and B without error (and get a 
configuration that contains both) because there isn't any module that 
reads both. If you had module C that requires both A and B then you'd 
get an error to say that A and B export com.single.package to C.


So this is why it succeeds at link time. There isn't any notion of class 
loader at link time and jlink cannot know how the modules will be mapped 
to loaders at run time. jlink could assume that all modules will likely 
be defined to the same class loader and thus reject the above but it 
doesn't.


As to whether the resulting run time image is useful or not then it 
depends on the initial module. If the initial module is C that only 
requires A then it will work, same thing if the initial module is D that 
only requires B. On the other hand, if you do `java -jar X.jar` then the 
initial module is the unnamed module, which by convention, will cause 
all modules in the runtime image with an API to be resolved (the module 
system does not know anything about what X needs). In that scenario when 
A and B will be resolved but will fail when attempting to map both to 
the application class loader. I will guess that is what promoted your mail.


-Alan

Re: RFR: 8156499 Update jlink to support creating images with modules that are packaged as multi-release JARs

[Steve Drach]

Hi,

Please review the latest webrev for this issue.

issue: https://bugs.openjdk.java.net/browse/JDK-8156499 

webrev: http://cr.openjdk.java.net/~sdrach/8156499/webrev.03/ 


I believe this changeset resolves all the issues Alan and Mandy had with the 
previous changesets.  They are:

1. the test silently passes if java.base.jmod can not be found on the 
module-path
2. the test assures that
a. the correct module-info class is in the module image
b. the correct resource file is in the module image
c. the correct class file is in the module image
3. As before, the image module created is for the Runtime.Version of jlink.  
This demonstrates that MMR jar files
are handled correctly, but will have to be updated to create an image based 
on the Runtime.Version of java.base
when the appropriate code is migrated from jake.

Thanks,
Steve

Re: RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

[Alan Bateman]

On 12/10/2016 16:33, Sundararajan Athijegannathan wrote:


:

Dynalink used to automatically add those necessary add edges. With the
current change, nashorn adds necessary read edges. CallerSensitive
methods are found only in java.base, java.logging, java.sql and
java.sql.rowset modules - the first two are always present [in nashorn's
compact1 dependency world]. The later two are checked for presence and
read-edges are added conditionally (see ScriptLoader.java changes).
JDK-8154346 tracks fixing java.sql.DriverManager, there are 
compatibility concerns to changing it but it is being looked at.


I'm not familiar with the issue in the java.sql.rowset module but it may 
be that the security checks in SerialJavaObject::getFields can be 
re-visited (I don't know all the history on that).





Yes, I need boot layer modules only and I'll change that.


Thanks.

-Alan.

Review Request: JDK-8167558 Add new JMOD section for header files and man pages

[Mandy Chung]

Webrev:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8167558/webrev.00/

Header files and man pages are currently copied to the image. The header files 
are modularized and in the following directory:
   src/$MODULE/share/native/include 

The man page for the corresponding tool should also be modularized.

This patch proposes to add a JMOD section for include header files and one for 
man pages such that they should be packaged in a JMOD file of the module they 
belong to.

Two new jmod options are added:
  --header-files   Location of header files
  --man-pages  Location of man pages 

jlink will install the header files and man pages under the `include` directory 
and `man` directory respectively.

jlink provides options to exclude header files or man page.

  --no-man-pagesExclude man pages
  --no-header-files Exclude include header files

Or use --exclude-jmod-section plugin to filter `man` or `headers` section of 
specific modules rather than all.

Option is:
   
--exclude-jmod-section=[:modules=(,)*]

where  is "man" or "headers”.

-—no-man-pages is equivalent to --exclude-jmod-section=man
-—no-header-files is equivalent to --exclude-jmod-section=headers

—-exclude-jmod-section can only be specified once for each section type.  

This patch packages the header files in JDK's JMOD files.  The man pages are 
yet to be modularized and CreateJmods.gmk has the change to prepare for it to 
come.

Mandy

Re: JEP-282: JLink two modules exporting the same package name

[Sundararajan Athijegannathan]

If you want to enforce that kind of consistency - that no two
application modules should export same named package - it should be
possible to implement a user defined jlink plugin to enforce the same.

-Sundar

On 10/13/2016 12:35 AM, Alan Bateman wrote:
> On 12/10/2016 19:17, Karl Heinz Marbaise wrote:
>
>> Hi,
>>
>> i have a question concerning the jlink command in JDK 9..(EA +138 build)
>>
>> I have created two modules lets call them module A and module B
>> (module-info.java):
>>
>> module A {
>>requires java.base;
>>exports com.single.package;
>> }
>>
>> module B {
>>requires java.base;
>>exports com.single.package;
>> }
>>
>> both export the same package: com.single.package
>>
>> The question is: Shouldn't the jlink command fail in such cases cause
>> both modules export the same package ?
>>
>> Otherwise it would mean to fail at the time of starting the generated
>> JVM image which I think is too late...
> You can resolve independent modules A and B without error (and get a
> configuration that contains both) because there isn't any module that
> reads both. If you had module C that requires both A and B then you'd
> get an error to say that A and B export com.single.package to C.
>
> So this is why it succeeds at link time. There isn't any notion of
> class loader at link time and jlink cannot know how the modules will
> be mapped to loaders at run time. jlink could assume that all modules
> will likely be defined to the same class loader and thus reject the
> above but it doesn't.
>
> As to whether the resulting run time image is useful or not then it
> depends on the initial module. If the initial module is C that only
> requires A then it will work, same thing if the initial module is D
> that only requires B. On the other hand, if you do `java -jar X.jar`
> then the initial module is the unnamed module, which by convention,
> will cause all modules in the runtime image with an API to be resolved
> (the module system does not know anything about what X needs). In that
> scenario when A and B will be resolved but will fail when attempting
> to map both to the application class loader. I will guess that is what
> promoted your mail.
>
> -Alan