Re: StackOverflowError - Java 9 Build 181

[Tom Hood]

I should add that we have not modified or overridden any policy files.
Also, we are not using a custom security manager.

On Tue, Sep 19, 2017 at 11:52 AM, Tom Hood <tom.w.h...@gmail.com> wrote:

> Hi,
>
> I hit an infinite recursion loop probably related to PolicyFile that
> exists in Java 9 build 181 for windows 64-bit.  It might be related to
> JDK-8077418 <https://bugs.openjdk.java.net/browse/JDK-8077418>
>
> I haven't tracked down what is causing our webstart app to hit this
> problem yet, but I thought I would let you know sooner than later.  Also,
> it probably is not a problem for our particular application as I should be
> able to set the security manager to null which I think/hope will bypass
> this issue.  I will try today to reproduce it in our app so I can confirm
> if setting security manager to null will work for us.
>
> The stack looks like the following: (with many repeat stacks omitted)
>
> Exception in thread "AWT-EventQueue-2" java.lang.StackOverflowError
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/sun.security.provider.PolicyFile.getPermissions(Po
> licyFile.java:1135)
> at java.base/sun.security.provider.PolicyFile.getPermissions(Po
> licyFile.java:1082)
> at java.base/sun.security.provider.PolicyFile.implies(PolicyFil
> e.java:1038)
> at java.base/java.security.provider.ProtectionDomain.implies(Pr
> otectionDomain.java:323)
> at java.base/java.security.provider.ProtectionDomain.impliesWit
> hAltFilePerm(ProtectionDomain.java:355)
> at java.base/java.security.provider.AccessControlContext.checkP
> ermission(AccessControlContext.java:450)
> at java.base/java.security.provider.AccessController.checkPermi
> ssion(AccessController.java:895)
> at java.base/java.lang.SecurityManager.checkPermission(Security
> Manager.java:558)
> at jdk.javaws/com.sun.javaws.security.JavaWebStartSecurity.chec
> kPermission(JavaWebStartSecurity.java:237)
> at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:897)
> at java.base/java.io.File.isDirectory(File.java:845)
> at java.base/sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:299)
> at java.base/sun.security.provider.PolicyFile.canonicalizeCodeb
> ase(PolicyFile.java:1665)
> at java.base/sun.security.provider.PolicyFile.access$700(Policy
> File.java:263)
> at java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1139)
> at java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1136)
>  and again 
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/sun.security.provider.PolicyFile.getPermissions(Po
> licyFile.java:1135)
> at java.base/sun.security.provider.PolicyFile.getPermissions(Po
> licyFile.java:1082)
> at java.base/sun.security.provider.PolicyFile.implies(PolicyFil
> e.java:1038)
> at java.base/java.security.provider.ProtectionDomain.implies(Pr
> otectionDomain.java:323)
> at java.base/java.security.provider.ProtectionDomain.impliesWit
> hAltFilePerm(ProtectionDomain.java:355)
> at java.base/java.security.provider.AccessControlContext.checkP
> ermission(AccessControlContext.java:450)
> at java.base/java.security.provider.AccessController.checkPermi
> ssion(AccessController.java:895)
> at java.base/java.lang.SecurityManager.checkPermission(Security
> Manager.java:558)
> at jdk.javaws/com.sun.javaws.security.JavaWebStartSecurity.chec
> kPermission(JavaWebStartSecurity.java:237)
> at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:897)
> at java.base/java.io.File.isDirectory(File.java:845)
> at java.base/sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:299)
> at java.base/sun.security.provider.PolicyFile.canonicalizeCodeb
> ase(PolicyFile.java:1665)
> at java.base/sun.security.provider.PolicyFile.access$700(Policy
> File.java:263)
> at java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1139)
> at java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1136)
>  above lines start the stack that repeats until overflow 
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/sun.security.provider.PolicyFile.getPermissions(Po
> licyFile.java:1135)
> at java.base/sun.security.provider.PolicyFile.getPermissions(Po
> licyFile.java:1082)
> at java.base/sun.security.provider.PolicyFile.implies(PolicyFil
> e.java:1038)
>
> -- Tom
>
>

StackOverflowError - Java 9 Build 181

[Tom Hood]

Hi,

I hit an infinite recursion loop probably related to PolicyFile that exists
in Java 9 build 181 for windows 64-bit.  It might be related to JDK-8077418


I haven't tracked down what is causing our webstart app to hit this problem
yet, but I thought I would let you know sooner than later.  Also, it
probably is not a problem for our particular application as I should be
able to set the security manager to null which I think/hope will bypass
this issue.  I will try today to reproduce it in our app so I can confirm
if setting security manager to null will work for us.

The stack looks like the following: (with many repeat stacks omitted)

Exception in thread "AWT-EventQueue-2" java.lang.StackOverflowError
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/sun.security.provider.PolicyFile.getPermissions(
PolicyFile.java:1135)
at java.base/sun.security.provider.PolicyFile.getPermissions(
PolicyFile.java:1082)
at java.base/sun.security.provider.PolicyFile.implies(PolicyFile.java:1038)
at java.base/java.security.provider.ProtectionDomain.implies(
ProtectionDomain.java:323)
at java.base/java.security.provider.ProtectionDomain.impliesWit
hAltFilePerm(ProtectionDomain.java:355)
at java.base/java.security.provider.AccessControlContext.checkP
ermission(AccessControlContext.java:450)
at java.base/java.security.provider.AccessController.checkPermi
ssion(AccessController.java:895)
at java.base/java.lang.SecurityManager.checkPermission(Security
Manager.java:558)
at jdk.javaws/com.sun.javaws.security.JavaWebStartSecurity.chec
kPermission(JavaWebStartSecurity.java:237)
at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:897)
at java.base/java.io.File.isDirectory(File.java:845)
at java.base/sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:299)
at java.base/sun.security.provider.PolicyFile.canonicalizeCodeb
ase(PolicyFile.java:1665)
at java.base/sun.security.provider.PolicyFile.access$700(
PolicyFile.java:263)
at java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1139)
at java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1136)
 and again 
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/sun.security.provider.PolicyFile.getPermissions(
PolicyFile.java:1135)
at java.base/sun.security.provider.PolicyFile.getPermissions(
PolicyFile.java:1082)
at java.base/sun.security.provider.PolicyFile.implies(PolicyFile.java:1038)
at java.base/java.security.provider.ProtectionDomain.implies(
ProtectionDomain.java:323)
at java.base/java.security.provider.ProtectionDomain.impliesWit
hAltFilePerm(ProtectionDomain.java:355)
at java.base/java.security.provider.AccessControlContext.checkP
ermission(AccessControlContext.java:450)
at java.base/java.security.provider.AccessController.checkPermi
ssion(AccessController.java:895)
at java.base/java.lang.SecurityManager.checkPermission(Security
Manager.java:558)
at jdk.javaws/com.sun.javaws.security.JavaWebStartSecurity.chec
kPermission(JavaWebStartSecurity.java:237)
at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:897)
at java.base/java.io.File.isDirectory(File.java:845)
at java.base/sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:299)
at java.base/sun.security.provider.PolicyFile.canonicalizeCodeb
ase(PolicyFile.java:1665)
at java.base/sun.security.provider.PolicyFile.access$700(
PolicyFile.java:263)
at java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1139)
at java.base/sun.security.provider.PolicyFile$7.run(PolicyFile.java:1136)
 above lines start the stack that repeats until overflow 
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/sun.security.provider.PolicyFile.getPermissions(
PolicyFile.java:1135)
at java.base/sun.security.provider.PolicyFile.getPermissions(
PolicyFile.java:1082)
at java.base/sun.security.provider.PolicyFile.implies(PolicyFile.java:1038)

-- Tom

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

[Tom Hood]

On Wed, Aug 23, 2017 at 6:36 AM, Alan Bateman <alan.bate...@oracle.com>
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

[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 <mandy.ch...@oracle.com> 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 <tom.w.h...@gmail.com> wrote:
>>
>> I found Alan's video <https://www.youtube.com/watch?v=eU8hCCjGSbE> (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 <tom.w.h...@gmail.com> 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 o

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 <tom.w.h...@gmail.com> wrote:

> I found Alan's video <https://www.youtube.com/watch?v=eU8hCCjGSbE> (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 <tom.w.h...@gmail.com> 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 <https://www.youtube.com/watch?v=eU8hCCjGSbE> (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 <tom.w.h...@gmail.com> 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
>
>

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

Re: JDK 9 jar tool issues - "isolated nested class" and creation of a corrupt jar

[Tom Hood]

Glad you were able to reproduce it.  Thanks for creating the JBS issue.

On Thu, Aug 10, 2017 at 11:49 AM, mandy chung <mandy.ch...@oracle.com>
wrote:

>
>
> On 8/9/17 4:50 PM, Tom Hood wrote:
>
>> Hi,
>>
>> I'm having a couple issues with the jar tool. Version: JDK 9 build 181
>> SPARC64
>>
>> Since I'm typing this in, beware of typos.  I cannot copy and paste output
>> as my Solaris 10 box isn't permitted to access the internet.
>>
>> (1) isolated nested classes trying to create a multi-release jar
>>
>
> I can reproduce the isolated nested class error.   It seems a bug in how
> it validates a nested class when its enclosing class is a nested class.  I
> create a JBS issue to track it:
>https://bugs.openjdk.java.net/browse/JDK-8186087
>
> We will look into it and provide answers to the ordering of the entry list
> and also corrupted JAR on sparc64.
>
> Mandy
>

JDK 9 jar tool issues - "isolated nested class" and creation of a corrupt jar

[Tom Hood]

Hi,

I'm having a couple issues with the jar tool. Version: JDK 9 build 181
SPARC64

Since I'm typing this in, beware of typos.  I cannot copy and paste output
as my Solaris 10 box isn't permitted to access the internet.

(1) isolated nested classes trying to create a multi-release jar

In my test case (which I can't give you as it's on a different network), I
have a number of classes compiled for java 6  (javac --release 6) and then
1 compiled for both java 6 and java 9.  The java 9 version is in a "v9"
subdirectory.

The complete directory structure looks likes this:

./v9/com/thirdparty/jdk/JdkSpecificClass.class
./com/thirdparty/jdk/JdkSpecificClass.class
./com/thirdparty/animation/CustomAnimation.class
./com/thirdparty/animation/CustomAnimation$0.class
./com/thirdparty/animation/CustomAnimation$BackgroundPanel.class
./com/thirdparty/animation/CustomAnimation$Callback.class
./com/thirdparty/animation/CustomAnimation$n_.class
./com/thirdparty/animation/CustomAnimation$1.class
./com/thirdparty/animation/CustomAnimation$2.class
./com/thirdparty/animation/CustomAnimation$3.class
./com/thirdparty/animation/CustomAnimation$3$0.class
./com/thirdparty/animation/CustomAnimation$3$1.class
./com/thirdparty/animation/CustomAnimation$4.class
./com/thirdparty/animation/CustomAnimation$4$0.class
./com/thirdparty/animation/CustomAnimation$4$1.class
./com/thirdparty/animation/CustomAnimation$5.class
./com/thirdparty/animation/CustomAnimation$6.class
./com/thirdparty/animation/CustomAnimation$7.class
./com/thirdparty/animation/CustomAnimation$8.class
./com/thirdparty/animation/CustomAnimation$9.class
./com/thirdparty/animation/CustomAnimation$10.class
./com/thirdparty/animation/CustomAnimation$11.class
./com/thirdparty/animation/CustomAnimation$12.class
./com/thirdparty/animation/CustomAnimation$12$1.class
./com/thirdparty/animation/CustomAnimation$12$2.class
./com/thirdparty/animation/CustomAnimation$13.class
./com/thirdparty/animation/CustomAnimation$13$1.class
./com/thirdparty/animation/CustomAnimation$13$2.class

>From that directory, I run the following jar command:

  jar cvf test.jar com --release 9 -C v9 com

It outputs the following:  (I'm not typing the "(in = N) (out= M)(deflated
P%)" text..if you need it, let me know)

added manifest
adding: com/
adding: com/thirdparty/
adding: com/thirdparty/animation/
adding: com/thirdparty/animation/CustomAnimation$0.class # should
CustomAnimation.class go first?
adding: com/thirdparty/animation/CustomAnimation$1.class
adding: com/thirdparty/animation/CustomAnimation$10.class
adding: com/thirdparty/animation/CustomAnimation$11.class
adding: com/thirdparty/animation/CustomAnimation$12$1.class  # should
CustomAnimation$12.class go first?
adding: com/thirdparty/animation/CustomAnimation$12$2.class
adding: com/thirdparty/animation/CustomAnimation$12.class
adding: com/thirdparty/animation/CustomAnimation$13$1.class  #should
CustomAnimation$13.class go first?
adding: com/thirdparty/animation/CustomAnimation$13$2.class
adding: com/thirdparty/animation/CustomAnimation$13.class
adding: com/thirdparty/animation/CustomAnimation$2.class
adding: com/thirdparty/animation/CustomAnimation$3$0.class #ditto above
comment
adding: com/thirdparty/animation/CustomAnimation$3$1.class
adding: com/thirdparty/animation/CustomAnimation$3.class
adding: com/thirdparty/animation/CustomAnimation$4$0.class #ditto above
comment
adding: com/thirdparty/animation/CustomAnimation$4$1.class
adding: com/thirdparty/animation/CustomAnimation$4.class
adding: com/thirdparty/animation/CustomAnimation$5.class
adding: com/thirdparty/animation/CustomAnimation$6.class
adding: com/thirdparty/animation/CustomAnimation$7.class
adding: com/thirdparty/animation/CustomAnimation$8.class
adding: com/thirdparty/animation/CustomAnimation$9.class
adding: com/thirdparty/animation/CustomAnimation$BackgroundPanel.class
adding: com/thirdparty/animation/CustomAnimation$Callback.class
adding: com/thirdparty/animation/CustomAnimation$n_.class
adding: com/thirdparty/animation/CustomAnimation.class
adding: com/thirdparty/jdk/
adding: com/thirdparty/jdk/JdkSpecificClass.class
adding: META-INF/versions/9/com/
adding: META-INF/versions/9/com/thirdparty/
adding: META-INF/versions/9/com/thirdparty/jdk/
adding: META-INF/versions/9/com/thirdparty/jdk/JdkSpecificClass.class
entry: com/thirdparty/animation/CustomAnimation$12$1.class, is an isolated
nested class
entry: com/thirdparty/animation/CustomAnimation$12$2.class, is an isolated
nested class
entry: com/thirdparty/animation/CustomAnimation$13$1.class, is an isolated
nested class
entry: com/thirdparty/animation/CustomAnimation$13$2.class, is an isolated
nested class
entry: com/thirdparty/animation/CustomAnimation$3$0.class, is an isolated
nested class
entry: com/thirdparty/animation/CustomAnimation$3$1.class, is an isolated
nested class
entry: com/thirdparty/animation/CustomAnimation$4$0.class, is an isolated
nested class
entry: com/thirdparty/animation/CustomAnimation$4$1.class, is an 

Re: JDK 9 org.omg.CORBA.ORBSingletonClass loading will not use context class loader

[Tom Hood]

I haven't tried JDK 9 yet.  I was assuming the 7u55 change in JDK 9 would
impact our application the same way.  I hope to try it next week as I'm
currently stuck testing on windows XP which limits me to 1.7 or earlier.
So maybe Approach #3 will be:  "It should just work"  [*I think I'm
required to add a quarter to some jar whenever I use that phrase*]:-)

That's good  to know about the java.corba module.  The vb jar does carry a
bunch of org.omg.* classes, so it sounds like with JDK 9 everything corba
related will be taken from the vb jar (assuming I don't explicitly use
--add-modules).

The realization I'm now having is that JDK 9 will use more code from the vb
jar than earlier versions did which I think will be a good thing.  The
scary thought is that right now we must be running in production with a
Frankenstein mix of some org.omg.* classes from the vb jar and some from
the JDK which could in theory vary across JDK updates, making the whole
thing more fragile in my mind.  I believe the parent-first model is used by
the JNLPClassLoader will choose the JDK version of a class over one with
the same name from the vb jar.  So the mixing of different ORB
implementations I was so concerned about is probably already the way we're
running?  Yikes!

That's also good to know about JDK 9 application class loader not being an
instance of URLClassLoader.  I'll probably use approach #1 when jre is
older than 9 so our app will work with the select versions of 6, 7, and 8
with the ORB.init() change.

Any thoughts on question 2 of approach #1 (i.e. disabling security manager
vs. granting the application AllPermission via policy file)?  It seems like
they should be equivalent.  I'm told it is near impossible to reliably get
IT at customer facilities to make desired modifications to the jre
installation, such as a policy file.

Thanks for all your help.  Looking forward to trying JDK 9 soon.


On Wed, Oct 19, 2016 at 12:48 AM, Alan Bateman <alan.bate...@oracle.com>
wrote:

> On 19/10/2016 03:28, Tom Hood wrote:
>
> It's unclear if there really is an interop issue.   The application will
> launch with 7u55 if I don't set the ORBSingletonClass property, although
> that isn't how visibroker 5.2.1 was intended to run, so not setting it
> worries me.
>
> Our application does call ORB.init(args,props) once at startup and use
> that instance throughout the code we have written.
>
> However, visibroker calls ORB.init() all over the idl generated code and
> the vb jar itself.
>
> The javap of the vb jar does show some downcasts to its
> com.inprise.vbroker.orb.ORBSingleton implementation in a few classes, but
> I haven't tracked down if that code could execute in our application or if
> the object it tries to downcast originated from ORB.init().  The simple
> test of a basic launch and performing some activities within the
> application seem to work.  Sadly we don't have any automated tests that
> exercise our use of CORBA (java client to/from c++ server).
>
> The idea of mixing ORB implementations worries me, even if only for the
> singleton ORB.  I'm new to CORBA and the client side of our application and
> still a newbie to java as I've been primarily working on our c++ server.
>
> Do the reasons for the JDK change to ORB.init() apply in our use case?
> There's only one application/context and ORB vendor implementation running
> in the jvm in production.  Do you think approach #1 might be a reasonably
> safe workaround without the risk of hidden interop issues?
>
> I can't tell from this thread if you have tried with JDK 9 or not (you've
> mentioned 7u55 a few times).
>
> I ask because in JDK 9 then the java.corba module is not resolved by
> default. If your application starts there then it suggests to me that
> Visibroker may be carrying its own copy of the org.omg.** (and RMI-IIOP)
> classes, in which case the JDK ORB (even singleton ORB) is not in the
> picture. Or maybe you've got past this and your JNLP contains:
>   
>
> which is the equivalent to the --add-modules command line option.
>
> Another comment is that if there is code calling the no-arg ORB.init and
> blinding casting the return to com.inprise.vbroker.orb.ORBSingleton then
> it will never work in the scenario where the system-wide singleton ORB has
> been initialized by before Visibroker is used. I completely agree that it
> would be unusual to mix different ORB implementations in the same VM but
> the API has always allowed for that.
>
> On approach #1 then one thing to be aware of is that the application class
> loader is not an instance of URLClassLoader in JDK 9. That is an
> implementation change that is known to trip up code that has been hacking
> into it.
>
> -Alan
>

Re: JDK 9 org.omg.CORBA.ORBSingletonClass loading will not use context class loader

[Tom Hood]

It's unclear if there really is an interop issue.   The application will
launch with 7u55 if I don't set the ORBSingletonClass property, although
that isn't how visibroker 5.2.1 was intended to run, so not setting it
worries me.

Our application does call ORB.init(args,props) once at startup and use that
instance throughout the code we have written.

However, visibroker calls ORB.init() all over the idl generated code and
the vb jar itself.

The javap of the vb jar does show some downcasts to its
com.inprise.vbroker.orb.ORBSingleton implementation in a few classes, but I
haven't tracked down if that code could execute in our application or if
the object it tries to downcast originated from ORB.init().  The simple
test of a basic launch and performing some activities within the
application seem to work.  Sadly we don't have any automated tests that
exercise our use of CORBA (java client to/from c++ server).

The idea of mixing ORB implementations worries me, even if only for the
singleton ORB.  I'm new to CORBA and the client side of our application and
still a newbie to java as I've been primarily working on our c++ server.

Do the reasons for the JDK change to ORB.init() apply in our use case?
There's only one application/context and ORB vendor implementation running
in the jvm in production.  Do you think approach #1 might be a reasonably
safe workaround without the risk of hidden interop issues?


On Tue, Oct 18, 2016 at 1:30 PM, Alan Bateman <alan.bate...@oracle.com>
wrote:

> On 18/10/2016 19:57, Tom Hood wrote:
>
> Hello,
>>
>> We have a Java Webstart application that uses CORBA and requires an old
>> version of the Visibroker ORB (5.2.1) that will not launch with Java 9 due
>> to its inclusion of a change originally added to 7u55 and later backed
>> out:
>> Bug ID: JDK-8042789 org.omg.CORBA.ORBSingletonClass loading no
>> longer uses context class loader
>> <http://bugs.java.com/view_bug.do?bug_id=8042789>
>>
>> What approaches should we consider for our application to support Java 9 ?
>>
>> The singleton ORB is the system-wide type code factory so having it be
> located via the TCCL is highly problematic (many reasons including
> security, memory leaks, and of course it's not going to work then there two
> or more applications/contexts in the same VM trying to do the same thing).
>
> I assume your application can use the 2-arg ORB.init to create the ORB, in
> which case the implementation will be located via the TCCL (so you can
> bundle the ORB implementation with the application). From your mail then it
> sounds like the issue is that something in Visibroker is using the zero-arg
> ORB.init and so gets the JDK ORB as the singleton ORB. Does this lead to an
> interop issue or does Visibroker assuming the singleton ORB is its own type?
>
> -Alan
>

JDK 9 org.omg.CORBA.ORBSingletonClass loading will not use context class loader

[Tom Hood]

Hello,

We have a Java Webstart application that uses CORBA and requires an old
version of the Visibroker ORB (5.2.1) that will not launch with Java 9 due
to its inclusion of a change originally added to 7u55 and later backed out:
   Bug ID: JDK-8042789 org.omg.CORBA.ORBSingletonClass loading no
longer uses context class loader


What approaches should we consider for our application to support Java 9 ?

Constraints we must satisfy:

   - cannot upgrade visibroker
   - continue to support clients with java versions 1.6+

Constraints we are trying to satisfy:

   - avoid using different vendor ORB
   - avoid replacing CORBA
   - avoid modifying user's machine configuration (e.g. CLASSPATH) or jre
   installation with application-specifics (i.e. java.security, java.policy,
   etc.)

The two properties we set in the jnlp to specify the visibroker orb classes
are:



The two approaches I'm considering so far are:

   1. add vb jar to system class loader at start of application using
   URLClassLoader.addURL
   2. edit vb jar to avoid calling org.omg.CORBA.ORB.init()


*Approach #1: add vb jar to system class loader at start of application*

This works with 7u55.  The application will launch as long as I disable the
security manager (System.setSecurityManager(null)) or use a policy file
entry that explicitly grants AllPermission to the vb jar.  This is
necessary even though our jnlp file has always specified
.  To add the vb jar to the system
class loader, it appears necessary to call the protected
URLClassLoader.addURL method via reflection.

Questions I have about Approach #1:

   1. Are there additional security concerns with disabling the security
   manager at the start of main instead of granting AllPermission via policy
   files?  Our goal is for our application to continue to have the same access
   the user has to the user's machine (mostly windows).  The users do not
   have/run our application with administrator/root privileges.
   2. Is there a better way to make the vb jar visible to the system class
   loader when the application starts without calling a protected addURL
   method?


*Approach #2: edit vb jar to avoid calling org.omg.CORBA.ORB.init()*

I haven't gone down this path too far other than attempt to identify edits
that would be needed.  The source is unavailable (javap and
http://asm.ow2.org have been helpful).  Here's the list of possible edits I
have so far:

   1. Replace calls to org.omg.CORBA.ORB.init() with a call to our own
   class such as AppORB.init() that always returns the vb ORBSingleton instance
   2. Replace any object that is being downcast to the vb ORBSingleton
   (and/or its subclasses, if any) with a call to AppORB.init()
   3. Check if vb jar calls methods in the jre which then call ORB.init().
   If such calls exist, then I think I may need to replace these calls with
   something equivalent, because otherwise the default jre provided singleton
   will be used (com.sun.corba.se.impl.orb.ORBSingleton).  Maybe it's okay to
   mix the two Singleton ORB implementations in the same jvm, but not knowing
   enough about CORBA at this point it seems like a potential problem.  The
   javadoc does say it is a restricted implementation allowing use as a
   TypeCode factory only, but I'm not sure yet if it is possible to mix and
   match TypeCodes from the two ORB implementations.  Feels a little dicey to
   me.


Please let me know if you can think of any alternate approaches to consider
or potential issues/solutions to the ones outlined above.

Thank you,
-- Tom

P.S. I also posted this question at
https://community.oracle.com/message/14072662#14072662