Re: Manifest Add-Exports vs. command line --add-exports

[Peter Levart]

Hi,

On 08/23/2017 11:24 PM, Tom Hood wrote:



The CLI options to export or open packages can be specified in JNLP file,
you shouldn't need to ask user to add them via the control panel. You can
predicate on the Java SE version too, i.e.
   


The issue is the limit on the *number* of args we can have in the
java-vm-args.  If you exceed the limit, the webstart app fails to launch
and displays a popup window with the text "too many args to run".

We need so many --add-exports and --add-opens that it's possible we won't
be able to fit them all in there.  At the moment, we are just under the
limit and I'm hoping further testing of our app doesn't push us over the
edge by revealing more --add-opens, for example.

I can't shrink the list of args by using --illegal-access=permit, because
that is disallowed in the jnlp.  I think I saw some correspondence from you
indicating you intentionally wanted the jnlp to explicitly list what was
needed.  Unfortunately, that won't work if you have too many to list.

Any chance you could change Java 9 to allow --illegal-access=permit in the
jnlp or alternatively increase the number of args allowed?


I think that this problem could be solved by WebStart composing the JVM 
arguments into a temporary file and using the new JDK 9 @ 
syntax to launch the app.


Any chance that WebStart gets open-sourced?

Regards, Peter

Re: Manifest Add-Exports vs. command line --add-exports

[Tom Hood]

On Wed, Aug 23, 2017 at 6:36 AM, Alan Bateman 
wrote:

> On 22/08/2017 01:49, Tom Hood wrote:
>
>> Thanks, Mandy.  I was beginning to think my followup question might have
>> gotten lost and I was considering a new post.
>>
>> I'm unable to get --illegal-access=permits to work for our webstart app by
>> setting it in the Java Control Panel with the 9+181 build.  It appears
>> webstart crashes when I do this.  I tried enabling tracing & logging from
>> the Java Control Panel "Advanced" tab, but couldn't find anything left
>> behind.
>>
> The value is "permit" (not "permits"). Just mentioning in case this is a
> simple typo here. Also it would be good to confirm that that "crashes"
> means it aborts with an error message rather than a hard crash.
>

Thanks.  It was just the typo you pointed out.

I attempted to launch our app from firefox and didn't get any feedback with
the typo there.  I didn't try running javaws from the command line.  Maybe
it outputs something informative in that case.


>
>
>> Setting a long list of --add-exports in the Java Control Panel *does* work
>> for our webstart app with the 9+181 build.  However, I don't believe this
>> is going to work for our customer who has 1000's of geographically
>> distributed users.  We have next to zero control over how/when system
>> administrators perform the java installations.  Likewise, asking all those
>> users to manually add the options themselves is too much to ask of them.
>> I
>> predict many complaints and calls to our help desk that our app doesn't
>> work with Java 9.
>>
>> Any chance of adding a more webstart-friendly "JEP260 last resort" for
>> Java
>> 9 ?  Our vendors need more time to remove dependencies from their
>> libraries.  I'm concerned that as we proceed in testing our app with Java
>> 9
>> that the list of JEP260-override options will grow.  For example, the
>> --add-opens was added due to an illegal setAccessible(true) reflection
>> call.
>>
> The CLI options to export or open packages can be specified in JNLP file,
> you shouldn't need to ask user to add them via the control panel. You can
> predicate on the Java SE version too, i.e.
>   
>

The issue is the limit on the *number* of args we can have in the
java-vm-args.  If you exceed the limit, the webstart app fails to launch
and displays a popup window with the text "too many args to run".

We need so many --add-exports and --add-opens that it's possible we won't
be able to fit them all in there.  At the moment, we are just under the
limit and I'm hoping further testing of our app doesn't push us over the
edge by revealing more --add-opens, for example.

I can't shrink the list of args by using --illegal-access=permit, because
that is disallowed in the jnlp.  I think I saw some correspondence from you
indicating you intentionally wanted the jnlp to explicitly list what was
needed.  Unfortunately, that won't work if you have too many to list.

Any chance you could change Java 9 to allow --illegal-access=permit in the
jnlp or alternatively increase the number of args allowed?


>
> Have you submitted bugs to the JAI project about its usages of sun.* APIs?
>


-Alan
>

No I haven't and I'm not sure how, although I didn't try to find a link to
submit bugs to it.

I'm getting the impression the JAI plugin for ImageIO was taken over by
https://github.com/jai-imageio/jai-imageio-core.  I was about to give that
one a try instead of the one I got from Oracle:  http://www.oracle.com/
technetwork/java/javasebusiness/downloads/java-
archive-downloads-java-client-419417.html

If you know I'm headed in the wrong direction with that, please let me know.

Thanks,
-- Tom

Re: Manifest Add-Exports vs. command line --add-exports

[mandy chung]

On 8/23/17 6:36 AM, Alan Bateman wrote:

On 22/08/2017 01:49, Tom Hood wrote:

Thanks, Mandy.  I was beginning to think my followup question might have
gotten lost and I was considering a new post.

I'm unable to get --illegal-access=permits to work for our webstart 
app by

setting it in the Java Control Panel with the 9+181 build.  It appears
webstart crashes when I do this.  I tried enabling tracing & logging 
from

the Java Control Panel "Advanced" tab, but couldn't find anything left
behind.
The value is "permit" (not "permits"). Just mentioning in case this is 
a simple typo here. Also it would be good to confirm that that 
"crashes" means it aborts with an error message rather than a hard crash.




Thanks for catching the typo.

Mandy

Re: Manifest Add-Exports vs. command line --add-exports

[Alan Bateman]

On 22/08/2017 01:49, Tom Hood wrote:

Thanks, Mandy.  I was beginning to think my followup question might have
gotten lost and I was considering a new post.

I'm unable to get --illegal-access=permits to work for our webstart app by
setting it in the Java Control Panel with the 9+181 build.  It appears
webstart crashes when I do this.  I tried enabling tracing & logging from
the Java Control Panel "Advanced" tab, but couldn't find anything left
behind.
The value is "permit" (not "permits"). Just mentioning in case this is a 
simple typo here. Also it would be good to confirm that that "crashes" 
means it aborts with an error message rather than a hard crash.




Setting a long list of --add-exports in the Java Control Panel *does* work
for our webstart app with the 9+181 build.  However, I don't believe this
is going to work for our customer who has 1000's of geographically
distributed users.  We have next to zero control over how/when system
administrators perform the java installations.  Likewise, asking all those
users to manually add the options themselves is too much to ask of them.  I
predict many complaints and calls to our help desk that our app doesn't
work with Java 9.

Any chance of adding a more webstart-friendly "JEP260 last resort" for Java
9 ?  Our vendors need more time to remove dependencies from their
libraries.  I'm concerned that as we proceed in testing our app with Java 9
that the list of JEP260-override options will grow.  For example, the
--add-opens was added due to an illegal setAccessible(true) reflection call.
The CLI options to export or open packages can be specified in JNLP 
file, you shouldn't need to ask user to add them via the control panel. 
You can predicate on the Java SE version too, i.e.

  

Have you submitted bugs to the JAI project about its usages of sun.* APIs?

-Alan

Re: Manifest Add-Exports vs. command line --add-exports

[Tom Hood]

Thanks, Mandy.  I was beginning to think my followup question might have
gotten lost and I was considering a new post.

I'm unable to get --illegal-access=permits to work for our webstart app by
setting it in the Java Control Panel with the 9+181 build.  It appears
webstart crashes when I do this.  I tried enabling tracing & logging from
the Java Control Panel "Advanced" tab, but couldn't find anything left
behind.

Setting a long list of --add-exports in the Java Control Panel *does* work
for our webstart app with the 9+181 build.  However, I don't believe this
is going to work for our customer who has 1000's of geographically
distributed users.  We have next to zero control over how/when system
administrators perform the java installations.  Likewise, asking all those
users to manually add the options themselves is too much to ask of them.  I
predict many complaints and calls to our help desk that our app doesn't
work with Java 9.

Any chance of adding a more webstart-friendly "JEP260 last resort" for Java
9 ?  Our vendors need more time to remove dependencies from their
libraries.  I'm concerned that as we proceed in testing our app with Java 9
that the list of JEP260-override options will grow.  For example, the
--add-opens was added due to an illegal setAccessible(true) reflection call.

BTW: I had a slightly longer than necessary list of java-vm-args in my
original email in this thread.  After correcting that issue, I am now able
to launch our webstart app without editing the Java Control Panel as we are
just under the java command line arg limit.  So maybe we'll get lucky and
further testing won't find any new JEP260-override options that are
needed.  Knock on wood.

-- Tom

On Mon, Aug 21, 2017 at 3:50 PM, mandy chung  wrote:

>
>
> On 8/16/17 2:14 PM, Tom Hood wrote:
>
>> Thanks Richard.  Sorry I didn't see your post before hitting send.
>>
>> So does this mean there is no workaround for a webstart app that requires
>> a
>> lot of the --add-export options?
>>
>
> The only workaround I can think of is to set in Java Control Panel with
> `--add-exports` or `--illegal-access=permits` options.
>
> The long term solution is to request the library maintainer to eliminate
> their dependency on JDK internal APIs.
>
> Mandy
>
>> On Wed, Aug 16, 2017 at 2:12 PM, Tom Hood  wrote:
>>
>> I found Alan's video  (time:
>>> about 27:35) that goes with the slides pdf link and he mentions the
>>> Add-Exports line need to go in the manifest of the jar with the
>>> Main-Class.  I just now tried that and it still didn't take effect.  I'm
>>> still getting the same error:
>>>
>>> java.lang.IllegalAccessError: class com.sun.media.imageioimpl.plug
>>> ins.pnm.PNMImageWriter
>>> (in unamed module @0x52a256fc) cannot access class
>>> sun.security.action.GetPropertyAction
>>> (in module java.base) because module java.base does not export
>>> sun.security.action to unnamed module @0x52a256fc
>>>at com.sun.media.imageioimpl.plugins.pnm.PNMImageWriter.<
>>> init>[PNMImageWriter.java:85]
>>>
>>> The META-INF/MANIFEST.MF looks like this:
>>>
>>> Manifest-Version: 1.0
>>> Trusted-Library: true
>>> Application-Library-Allowable-Codebase: *
>>> Application-Name: TheName
>>> Permissions: all-permissions
>>> *Add-Exports: java.base/sun.security.action*
>>>
>>> Created-By: 1.6.0_24 (Sun Microsystems Inc.)
>>> Caller-Allowable-Codebase: *
>>> Main-Class: path.to.TheMainClass
>>> Codebase: *
>>>
>>> Name: path/to/a/file.class
>>> SHA1-Digest: thedigest
>>>
>>> (many more such class+digest pairs)
>>>
>>> Should this work or am I using it incorrectly?
>>>
>>> Thanks,
>>> -- Tom
>>>
>>> On Wed, Aug 16, 2017 at 1:30 PM, Tom Hood  wrote:
>>>
>>> Hi,

 I need a little help understanding the difference between "Add-Exports:"
 in a jar's manifest vs. the command line arg --add-exports.  I can get
 --add-exports to work, but not Add-Exports.

 JDK Version: 9 build 181 windows 64

 Slide 23 of http://openjdk.java.net/projec
 ts/jigsaw/talks/prepare-for-jd
 k9-j1-2016.pdf seems to suggest Add-Exports in the manifest as an
 alternative to --add-exports

 Our webstart-launched app requires a long list of --add-module and/or
 --add-exports command line options.  The list is long enough that it
 exceeds a limit on number of args and webstart fails to launch the app
 with
 the popup "too many args to run".

 Specifically, I was trying to allow jai_imageio.jar (1.0_01) to access
 java.base/sun.security.action by adding --add-exports=java.base/sun.se
 curity.action=ALL-UNNAMED
 to the java-vm-args in the jnlp.  However, that one additional arg
 pushed
 it over the edge and exceeded the limit.

 This is the full j2se element in our jnlp:

 >>>   java-vm-args="--add-modules=java.corba --add-exports
 java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED --add-exports
 java.desktop/sun.

Re: Manifest Add-Exports vs. command line --add-exports

[mandy chung]

On 8/16/17 2:14 PM, Tom Hood wrote:

Thanks Richard.  Sorry I didn't see your post before hitting send.

So does this mean there is no workaround for a webstart app that requires a
lot of the --add-export options?


The only workaround I can think of is to set in Java Control Panel with 
`--add-exports` or `--illegal-access=permits` options.


The long term solution is to request the library maintainer to eliminate 
their dependency on JDK internal APIs.


Mandy

On Wed, Aug 16, 2017 at 2:12 PM, Tom Hood  wrote:


I found Alan's video  (time:
about 27:35) that goes with the slides pdf link and he mentions the
Add-Exports line need to go in the manifest of the jar with the
Main-Class.  I just now tried that and it still didn't take effect.  I'm
still getting the same error:

java.lang.IllegalAccessError: class 
com.sun.media.imageioimpl.plugins.pnm.PNMImageWriter
(in unamed module @0x52a256fc) cannot access class 
sun.security.action.GetPropertyAction
(in module java.base) because module java.base does not export
sun.security.action to unnamed module @0x52a256fc
   at com.sun.media.imageioimpl.plugins.pnm.PNMImageWriter.<
init>[PNMImageWriter.java:85]

The META-INF/MANIFEST.MF looks like this:

Manifest-Version: 1.0
Trusted-Library: true
Application-Library-Allowable-Codebase: *
Application-Name: TheName
Permissions: all-permissions
*Add-Exports: java.base/sun.security.action*
Created-By: 1.6.0_24 (Sun Microsystems Inc.)
Caller-Allowable-Codebase: *
Main-Class: path.to.TheMainClass
Codebase: *

Name: path/to/a/file.class
SHA1-Digest: thedigest

(many more such class+digest pairs)

Should this work or am I using it incorrectly?

Thanks,
-- Tom

On Wed, Aug 16, 2017 at 1:30 PM, Tom Hood  wrote:


Hi,

I need a little help understanding the difference between "Add-Exports:"
in a jar's manifest vs. the command line arg --add-exports.  I can get
--add-exports to work, but not Add-Exports.

JDK Version: 9 build 181 windows 64

Slide 23 of http://openjdk.java.net/projects/jigsaw/talks/prepare-for-jd
k9-j1-2016.pdf seems to suggest Add-Exports in the manifest as an
alternative to --add-exports

Our webstart-launched app requires a long list of --add-module and/or
--add-exports command line options.  The list is long enough that it
exceeds a limit on number of args and webstart fails to launch the app with
the popup "too many args to run".

Specifically, I was trying to allow jai_imageio.jar (1.0_01) to access
java.base/sun.security.action by adding 
--add-exports=java.base/sun.security.action=ALL-UNNAMED
to the java-vm-args in the jnlp.  However, that one additional arg pushed
it over the edge and exceeded the limit.

This is the full j2se element in our jnlp:



I then removed the last --add-exports to keep under the arg limit and
instead added an Add-Exports line to the jai_imageio.jar
META-INF/MANIFEST.MF

Add-Exports: java.base/sun.security.action

That doesn't appear to be taking affect.  Am I using it incorrectly?

Thanks,
-- Tom

Re: Manifest Add-Exports vs. command line --add-exports

[Tom Hood]

Thanks Richard.  Sorry I didn't see your post before hitting send.

So does this mean there is no workaround for a webstart app that requires a
lot of the --add-export options?

On Wed, Aug 16, 2017 at 2:12 PM, Tom Hood  wrote:

> I found Alan's video  (time:
> about 27:35) that goes with the slides pdf link and he mentions the
> Add-Exports line need to go in the manifest of the jar with the
> Main-Class.  I just now tried that and it still didn't take effect.  I'm
> still getting the same error:
>
> java.lang.IllegalAccessError: class 
> com.sun.media.imageioimpl.plugins.pnm.PNMImageWriter
> (in unamed module @0x52a256fc) cannot access class 
> sun.security.action.GetPropertyAction
> (in module java.base) because module java.base does not export
> sun.security.action to unnamed module @0x52a256fc
>   at com.sun.media.imageioimpl.plugins.pnm.PNMImageWriter.<
> init>[PNMImageWriter.java:85]
>
> The META-INF/MANIFEST.MF looks like this:
>
> Manifest-Version: 1.0
> Trusted-Library: true
> Application-Library-Allowable-Codebase: *
> Application-Name: TheName
> Permissions: all-permissions
> *Add-Exports: java.base/sun.security.action*
> Created-By: 1.6.0_24 (Sun Microsystems Inc.)
> Caller-Allowable-Codebase: *
> Main-Class: path.to.TheMainClass
> Codebase: *
>
> Name: path/to/a/file.class
> SHA1-Digest: thedigest
>
> (many more such class+digest pairs)
>
> Should this work or am I using it incorrectly?
>
> Thanks,
> -- Tom
>
> On Wed, Aug 16, 2017 at 1:30 PM, Tom Hood  wrote:
>
>> Hi,
>>
>> I need a little help understanding the difference between "Add-Exports:"
>> in a jar's manifest vs. the command line arg --add-exports.  I can get
>> --add-exports to work, but not Add-Exports.
>>
>> JDK Version: 9 build 181 windows 64
>>
>> Slide 23 of http://openjdk.java.net/projects/jigsaw/talks/prepare-for-jd
>> k9-j1-2016.pdf seems to suggest Add-Exports in the manifest as an
>> alternative to --add-exports
>>
>> Our webstart-launched app requires a long list of --add-module and/or
>> --add-exports command line options.  The list is long enough that it
>> exceeds a limit on number of args and webstart fails to launch the app with
>> the popup "too many args to run".
>>
>> Specifically, I was trying to allow jai_imageio.jar (1.0_01) to access
>> java.base/sun.security.action by adding 
>> --add-exports=java.base/sun.security.action=ALL-UNNAMED
>> to the java-vm-args in the jnlp.  However, that one additional arg pushed
>> it over the edge and exceeded the limit.
>>
>> This is the full j2se element in our jnlp:
>>
>> >  java-vm-args="--add-modules=java.corba --add-exports
>> java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED --add-exports
>> java.desktop/sun.swing=ALL-UNNAMED --add-exports
>> java.desktop/sun.awt=ALL-UNNAMED --add-exports
>> java.desktop/sun.awt.image=ALL-UNNAMED --add-exports
>> java.desktop/sun.awt.windows=ALL-UNNAMED --add-exports
>> java.desktop/sun.awt.shell=ALL-UNNAMED --add-exports
>> java.desktop/sun.awt.dnd=ALL-UNNAMED --add-exports
>> java.base/sun.security.action=ALL-UNNAMED --add-exports=java.base/sun.se
>> curity.action=ALL-UNNAMED"/>
>>
>> I then removed the last --add-exports to keep under the arg limit and
>> instead added an Add-Exports line to the jai_imageio.jar
>> META-INF/MANIFEST.MF
>>
>> Add-Exports: java.base/sun.security.action
>>
>> That doesn't appear to be taking affect.  Am I using it incorrectly?
>>
>> Thanks,
>> -- Tom
>>
>>
>

Re: Manifest Add-Exports vs. command line --add-exports

[Tom Hood]

I found Alan's video  (time:
about 27:35) that goes with the slides pdf link and he mentions the
Add-Exports line need to go in the manifest of the jar with the
Main-Class.  I just now tried that and it still didn't take effect.  I'm
still getting the same error:

java.lang.IllegalAccessError: class
com.sun.media.imageioimpl.plugins.pnm.PNMImageWriter (in unamed module
@0x52a256fc) cannot access class sun.security.action.GetPropertyAction (in
module java.base) because module java.base does not export
sun.security.action to unnamed module @0x52a256fc
  at
com.sun.media.imageioimpl.plugins.pnm.PNMImageWriter.[PNMImageWriter.java:85]

The META-INF/MANIFEST.MF looks like this:

Manifest-Version: 1.0
Trusted-Library: true
Application-Library-Allowable-Codebase: *
Application-Name: TheName
Permissions: all-permissions
*Add-Exports: java.base/sun.security.action*
Created-By: 1.6.0_24 (Sun Microsystems Inc.)
Caller-Allowable-Codebase: *
Main-Class: path.to.TheMainClass
Codebase: *

Name: path/to/a/file.class
SHA1-Digest: thedigest

(many more such class+digest pairs)

Should this work or am I using it incorrectly?

Thanks,
-- Tom

On Wed, Aug 16, 2017 at 1:30 PM, Tom Hood  wrote:

> Hi,
>
> I need a little help understanding the difference between "Add-Exports:"
> in a jar's manifest vs. the command line arg --add-exports.  I can get
> --add-exports to work, but not Add-Exports.
>
> JDK Version: 9 build 181 windows 64
>
> Slide 23 of http://openjdk.java.net/projects/jigsaw/talks/prepare-for-
> jdk9-j1-2016.pdf seems to suggest Add-Exports in the manifest as an
> alternative to --add-exports
>
> Our webstart-launched app requires a long list of --add-module and/or
> --add-exports command line options.  The list is long enough that it
> exceeds a limit on number of args and webstart fails to launch the app with
> the popup "too many args to run".
>
> Specifically, I was trying to allow jai_imageio.jar (1.0_01) to access
> java.base/sun.security.action by adding 
> --add-exports=java.base/sun.security.action=ALL-UNNAMED
> to the java-vm-args in the jnlp.  However, that one additional arg pushed
> it over the edge and exceeded the limit.
>
> This is the full j2se element in our jnlp:
>
>   java-vm-args="--add-modules=java.corba --add-exports
> java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED --add-exports
> java.desktop/sun.swing=ALL-UNNAMED --add-exports
> java.desktop/sun.awt=ALL-UNNAMED --add-exports
> java.desktop/sun.awt.image=ALL-UNNAMED --add-exports
> java.desktop/sun.awt.windows=ALL-UNNAMED --add-exports
> java.desktop/sun.awt.shell=ALL-UNNAMED --add-exports
> java.desktop/sun.awt.dnd=ALL-UNNAMED --add-exports
> java.base/sun.security.action=ALL-UNNAMED --add-exports=java.base/sun.se
> curity.action=ALL-UNNAMED"/>
>
> I then removed the last --add-exports to keep under the arg limit and
> instead added an Add-Exports line to the jai_imageio.jar
> META-INF/MANIFEST.MF
>
> Add-Exports: java.base/sun.security.action
>
> That doesn't appear to be taking affect.  Am I using it incorrectly?
>
> Thanks,
> -- Tom
>
>

Re: Manifest Add-Exports vs. command line --add-exports

[Richard Opalka]

Hi Tom,

   Add-Exports option in manifest is used if and only if jar is
executed via 'java -jar your.jar' command.
The manifest Add-Exports option is ignored for jars on classpath.

Rio

On Wed, Aug 16, 2017 at 10:30 PM, Tom Hood  wrote:

> Hi,
>
> I need a little help understanding the difference between "Add-Exports:" in
> a jar's manifest vs. the command line arg --add-exports.  I can get
> --add-exports to work, but not Add-Exports.
>
> JDK Version: 9 build 181 windows 64
>
> Slide 23 of http://openjdk.java.net/projects/jigsaw/talks/prepare-
> for-jdk9-j1-2016.pdf seems to suggest Add-Exports in the manifest as an
> alternative to --add-exports
>
> Our webstart-launched app requires a long list of --add-module and/or
> --add-exports command line options.  The list is long enough that it
> exceeds a limit on number of args and webstart fails to launch the app with
> the popup "too many args to run".
>
> Specifically, I was trying to allow jai_imageio.jar (1.0_01) to access
> java.base/sun.security.action by adding
> --add-exports=java.base/sun.security.action=ALL-UNNAMED
> to the java-vm-args in the jnlp.  However, that one additional arg pushed
> it over the edge and exceeded the limit.
>
> This is the full j2se element in our jnlp:
>
>   java-vm-args="--add-modules=java.corba --add-exports
> java.desktop/com.sun.java.swing.plaf.windows=ALL-UNNAMED --add-exports
> java.desktop/sun.swing=ALL-UNNAMED --add-exports
> java.desktop/sun.awt=ALL-UNNAMED --add-exports
> java.desktop/sun.awt.image=ALL-UNNAMED --add-exports
> java.desktop/sun.awt.windows=ALL-UNNAMED --add-exports
> java.desktop/sun.awt.shell=ALL-UNNAMED --add-exports
> java.desktop/sun.awt.dnd=ALL-UNNAMED --add-exports
> java.base/sun.security.action=ALL-UNNAMED --add-exports=java.base/sun.se
> curity.action=ALL-UNNAMED"/>
>
> I then removed the last --add-exports to keep under the arg limit and
> instead added an Add-Exports line to the jai_imageio.jar
> META-INF/MANIFEST.MF
>
> Add-Exports: java.base/sun.security.action
>
> That doesn't appear to be taking affect.  Am I using it incorrectly?
>
> Thanks,
> -- Tom
>



-- 
--
Richard Opalka
Principal Software Engineer
Red Hat JBoss Middleware
Mobile: +420 731 186 942
E-mail: ropa...@redhat.com

Manifest Add-Exports vs. command line --add-exports

[Tom Hood]

Hi,

I need a little help understanding the difference between "Add-Exports:" in
a jar's manifest vs. the command line arg --add-exports.  I can get
--add-exports to work, but not Add-Exports.

JDK Version: 9 build 181 windows 64

Slide 23 of http://openjdk.java.net/projects/jigsaw/talks/prepare-
for-jdk9-j1-2016.pdf seems to suggest Add-Exports in the manifest as an
alternative to --add-exports

Our webstart-launched app requires a long list of --add-module and/or
--add-exports command line options.  The list is long enough that it
exceeds a limit on number of args and webstart fails to launch the app with
the popup "too many args to run".

Specifically, I was trying to allow jai_imageio.jar (1.0_01) to access
java.base/sun.security.action by adding
--add-exports=java.base/sun.security.action=ALL-UNNAMED
to the java-vm-args in the jnlp.  However, that one additional arg pushed
it over the edge and exceeded the limit.

This is the full j2se element in our jnlp:



I then removed the last --add-exports to keep under the arg limit and
instead added an Add-Exports line to the jai_imageio.jar
META-INF/MANIFEST.MF

Add-Exports: java.base/sun.security.action

That doesn't appear to be taking affect.  Am I using it incorrectly?

Thanks,
-- Tom