IllegalAccessException trying to load a ResourceBundle in 9u181

[mandy chung]

Hi all,
I'm not sure if core-libs is the right mailing list for jigsaw/modules
questions these days (rather than jigsaw-dev), so please feel free to
forward this there if it's the more appropriate list.

cc'ing  jigsaw-dev

I have the following code carried over from java 8 (actually much earlier
final Resource rb =
ResourceBundle.getBundle("sun.security.util.AuthResources");

Resource bundle follows the same encapsulation rule as described in
Module::getResourceAsStream [1] except that a resource bundle is
considered as a resource regardless of its format.

ResourceBundle.getBundle(String baseName) finds the specified resource
bundle from the caller's module.  It will first search the resource
bundle local in the caller's module (via Module::getResourceAsStream)
and then using the caller's class loader to search for the resource (via
ClassLoader::getResourceAsStream).   Since the caller is unnamed module
in your case, for it to access "sun.security.util.AuthResources",
java.base/sun.security.util has to be open unconditionally and there is
no CLI option to do that.

If you call ResourceBundle.getBundle("sun.security.util.AuthResources",
Object.class.getModule()) specifying the module of the resource bundle,
then you can break the encapsulation by `--add-opens
java.base/sun.security.util=ALL-UNNAMED`

I'm a bit surprised that you depend on JDK internal resource bundle. 
Can you help us understand why you use it?

Mandy
[1]
https://download.java.net/java/jdk10/docs/api/java/util/ResourceBundle.html#getBundle(java.lang.String,java.util.Locale,java.lang.Module)

[Vitaly Davidovich]

Hi Mandy,

Thanks very much for your response. Some comments inline ...

Hi all,
I'm not sure if core-libs is the right mailing list for jigsaw/modules
questions these days (rather than jigsaw-dev), so please feel free to
forward this there if it's the more appropriate list.
cc'ing jigsaw-dev
I have the following code carried over from java 8 (actually much earlier
final Resource rb =
ResourceBundle.getBundle("sun.security.util.AuthResources");
Resource bundle follows the same encapsulation rule as described in
Module::getResourceAsStream [1] except that a resource bundle is considered
as a resource regardless of its format.

Good to know - thanks.

ResourceBundle.getBundle(String baseName) finds the specified resource
bundle from the caller's module. It will first search the resource bundle
local in the caller's module (via Module::getResourceAsStream) and then
using the caller's class loader to search for the resource (via
ClassLoader::getResourceAsStream). Since the caller is unnamed module
in your case, for it to access "sun.security.util.AuthResources",
java.base/sun.security.util has to be open unconditionally and there is no
CLI option to do that.

Understood.

If you call ResourceBundle.getBundle("sun.security.util.AuthResources",
Object.class.getModule()) specifying the module of the resource bundle,
then you can break the encapsulation by `--add-opens
java.base/sun.security.util=ALL-UNNAMED`

So I tried calling getBundle(..., Object.class.getModule()), and that
worked - great. Interestingly, I didn't have to add-opens (or add-export
for that matter). Is that expected?

I'm a bit surprised that you depend on JDK internal resource bundle. Can
you help us understand why you use it?

Sigh. Yes, this is an ugly wart in the system, with lots of historical
baggage. The (really) short of it is we have a custom
javax.security.auth.spi.LoginModule implementation, which loads this
ResourceBundle (into a static final field). This is something that's being
addressed in parallel, but I'm trying to make some progress with migrating
the codebase to Java 9 in the meantime.

I should also mention that the real problem I'm troubleshooting is a
NoClassDefFoundError when this custom LoginModule is loaded. After some
class load/resolution tracing, it appears to me that the impl is found but
fails to initialize properly due to the ResourceBundle static field
initialization. That's what started me down a path of trying to minimize
the code and seeing what the issue is.

It's also worth mentioning that I'm trying to run the real code on the
9u181 JVM but with code compiled on Java 8 (we have a bunch of compile-time
issues to resolve so wanted to see if we can at least make progress on
running on a 9 JVM). I would like to try patching this custom login module
to use the new getBundle() overload that takes a Module, but I guess I'll
need to compile it with a java 9 javac. So yeah, it's ugly unfortunately.

Anyway, thanks for the help - I will try a few more things on my end. If
you have any suggestions to deal with this frankenstein setup I described
above, I'm all ears.

Mandy
[1] https://download.java.net/java/jdk10/docs/api/java/util/
ResourceBundle.html#getBundle(java.lang.String,java.util.
Locale,java.lang.Module)

[Alan Bateman]

Post by Vitaly Davidovich
So I tried calling getBundle(..., Object.class.getModule()), and that
worked - great. Interestingly, I didn't have to add-opens (or add-export
for that matter). Is that expected?

It works because the sun.security.util.AuthResources resource bundle for
the default locale is in java.base. You'll get MissingResourceException
once java.base is fully encapsulated (testing with --illegal-access=deny
to try it).

-Alan

[Vitaly Davidovich]

Post by Alan Bateman

Post by Vitaly Davidovich
So I tried calling getBundle(..., Object.class.getModule()), and that
worked - great. Interestingly, I didn't have to add-opens (or add-export
for that matter). Is that expected?
It works because the sun.security.util.AuthResources resource bundle for

the default locale is in java.base. You'll get MissingResourceException
once java.base is fully encapsulated (testing with --illegal-access=deny to
try it).

Right, thanks Alan. While we're on the subject, when do you expect
java.base to be fully encapsulated?

Post by Alan Bateman
-Alan

[Alan Bateman]

Right, thanks Alan.  While we're on the subject, when do you expect
java.base to be fully encapsulated?

TBD.