Re: #AddExportsInManifest

[Paul Bakker]

Got it! It makes sense after this example. As a bit of feedback: I do think the 
naming of the properties is confusing. Because they are the same as the 
--add-opens/--add-exports flags, my assumption was they would work (exactly) 
the same.
Naming things is hard, and I don't have a better alternative, but maybe a more 
descriptive name could be considered for the properties? 

Thanks,

Paul


> On May 12, 2017, at 12:26 AM, Alan Bateman  wrote:
> 
> On 11/05/2017 21:25, Paul Bakker wrote:
> 
>> I'm a little confused by "...deployments work if they are dependent on JDK 
>> internal APIs". What does internal JDK usage have to do with 
>> opening/exporting your own packages? I would think this solves the problem 
>> that some other code (e.g. a library) requires access to application code?
>> Also, can you elaborate why this only applies to the unnamed module and 
>> can't do the same a the --add-exports/--add-opens flags?
>> 
> Hopefully the mail that Mandy references gives the context.
> 
> As an example, suppose an executable JAR that has code that is hacking into 
> sun.awt.X11 for some reason. To keep that code working then you could do:
> 
> java --add-opens java.desktop/sun.awt.X11=ALL-UNNAMED -jar app.jar
> 
> but this isn't convenient for end-users that double click JAR files. The 
> equivalent for an executable JAR is to add "Add-Opens: java.desktop/sun.awt" 
> to its main manifest.
> 
> -Alan

Re: #AddExportsInManifest

[Alan Bateman]

On 11/05/2017 21:25, Paul Bakker wrote:


I'm a little confused by "...deployments work if they are dependent on JDK internal 
APIs". What does internal JDK usage have to do with opening/exporting your own 
packages? I would think this solves the problem that some other code (e.g. a library) 
requires access to application code?
Also, can you elaborate why this only applies to the unnamed module and can't 
do the same a the --add-exports/--add-opens flags?


Hopefully the mail that Mandy references gives the context.

As an example, suppose an executable JAR that has code that is hacking 
into sun.awt.X11 for some reason. To keep that code working then you 
could do:


java --add-opens java.desktop/sun.awt.X11=ALL-UNNAMED -jar app.jar

but this isn't convenient for end-users that double click JAR files. The 
equivalent for an executable JAR is to add "Add-Opens: 
java.desktop/sun.awt" to its main manifest.


-Alan

Re: #AddExportsInManifest

[Mandy Chung]

These two attributes are defined to ease migration so that executable JARs can 
run with java -jar command, as is today, to avoid adding command-line options 
to break into encapsulation.

Mandy
[1] http://openjdk.java.net/projects/jigsaw/spec/issues/#AddExportsInManifest

> On May 11, 2017, at 1:25 PM, Paul Bakker  wrote:
> 
> I'm a little confused by "...deployments work if they are dependent on JDK 
> internal APIs". What does internal JDK usage have to do with 
> opening/exporting your own packages? I would think this solves the problem 
> that some other code (e.g. a library) requires access to application code?
> Also, can you elaborate why this only applies to the unnamed module and can't 
> do the same a the --add-exports/--add-opens flags?
> 
> Note that I don't actually need these features, but I want to make sure I 
> document correctly.
> 
> Paul
> 
> 
>> On May 11, 2017, at 12:10 AM, Alan Bateman  wrote:
>> 
>> On 11/05/2017 07:51, Paul Bakker wrote:
>> 
>>> Hi Alan,
>>> 
>>> What is the reason only exports/opens to unnamed are possible?
>>> Also, are these implemented in the current jigsaw prototype? I'm having 
>>> trouble getting it to work, but that might be entirely my own doing...
>>> 
>> The attributes are defined for the main application JAR when run with `java 
>> -jar app.jar`. So there are defined to keep existing deployments work if 
>> they are dependent on JDK internal APIs.
>> 
>> The attributes have been in JDK 9 for a long time and I'm not aware of any 
>> issues. If it looks like it's not your "own doing" then send an example and 
>> we'll figure it out.
>> 
>> -Alan
> 

Re: #AddExportsInManifest

[Paul Bakker]

I'm a little confused by "...deployments work if they are dependent on JDK 
internal APIs". What does internal JDK usage have to do with opening/exporting 
your own packages? I would think this solves the problem that some other code 
(e.g. a library) requires access to application code?
Also, can you elaborate why this only applies to the unnamed module and can't 
do the same a the --add-exports/--add-opens flags?

Note that I don't actually need these features, but I want to make sure I 
document correctly.

Paul


> On May 11, 2017, at 12:10 AM, Alan Bateman  wrote:
> 
> On 11/05/2017 07:51, Paul Bakker wrote:
> 
>> Hi Alan,
>> 
>> What is the reason only exports/opens to unnamed are possible?
>> Also, are these implemented in the current jigsaw prototype? I'm having 
>> trouble getting it to work, but that might be entirely my own doing...
>> 
> The attributes are defined for the main application JAR when run with `java 
> -jar app.jar`. So there are defined to keep existing deployments work if they 
> are dependent on JDK internal APIs.
> 
> The attributes have been in JDK 9 for a long time and I'm not aware of any 
> issues. If it looks like it's not your "own doing" then send an example and 
> we'll figure it out.
> 
> -Alan

Re: #AddExportsInManifest

[Alan Bateman]

On 11/05/2017 07:51, Paul Bakker wrote:


Hi Alan,

What is the reason only exports/opens to unnamed are possible?
Also, are these implemented in the current jigsaw prototype? I'm having trouble 
getting it to work, but that might be entirely my own doing...

The attributes are defined for the main application JAR when run with 
`java -jar app.jar`. So there are defined to keep existing deployments 
work if they are dependent on JDK internal APIs.


The attributes have been in JDK 9 for a long time and I'm not aware of 
any issues. If it looks like it's not your "own doing" then send an 
example and we'll figure it out.


-Alan

Re: #AddExportsInManifest

[Paul Bakker]

Hi Alan,

What is the reason only exports/opens to unnamed are possible?
Also, are these implemented in the current jigsaw prototype? I'm having trouble 
getting it to work, but that might be entirely my own doing...

Thanks,

Paul

> On May 10, 2017, at 11:39 PM, Alan Bateman  wrote:
> 
> On 11/05/2017 07:22, Paul Bakker wrote:
> 
>> Hi all,
>> 
>> In #AddExportsInManifest two new manifest entries are proposed. I can only 
>> find the following email containing more details: 
>> http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2016-September/000547.html
>>  
>> .
>> Is this still current? I'm trying this in an example, but it doesn't seem to 
>> have any effect. Also, is the Add-Exports-Private replaced by Add-Opens?
>> 
>> The proposal only speaks about exporting to unnamed modules. Is it also 
>> possible to export to other modules? E.g. 'Add-Exports: m/p=othermodule?
>> 
> The attributes names are "Add-Exports" and "Add-Opens". JEP 261 needs a big 
> update and one of the things needed is to document these attributes in the 
> JEP (as they are JDK-specific attributes rather than attributes for the JAR 
> file spec).
> 
> As the attributes are for executable JAR files only then the effect is to 
> export or opens the packages to unnamed modules only (so no 
> `=` in the value).
> 
> -Alan

Re: #AddExportsInManifest

[Alan Bateman]

On 11/05/2017 07:22, Paul Bakker wrote:


Hi all,

In #AddExportsInManifest two new manifest entries are proposed. I can only find the 
following email containing more details: 
http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2016-September/000547.html 
.
Is this still current? I'm trying this in an example, but it doesn't seem to 
have any effect. Also, is the Add-Exports-Private replaced by Add-Opens?

The proposal only speaks about exporting to unnamed modules. Is it also 
possible to export to other modules? E.g. 'Add-Exports: m/p=othermodule?

The attributes names are "Add-Exports" and "Add-Opens". JEP 261 needs a 
big update and one of the things needed is to document these attributes 
in the JEP (as they are JDK-specific attributes rather than attributes 
for the JAR file spec).


As the attributes are for executable JAR files only then the effect is 
to export or opens the packages to unnamed modules only (so no 
`=` in the value).


-Alan