Hi Mandy,
Thanks very much for your response. Some comments inline ...
On Mon, Feb 12, 2018 at 7:44 PM, mandy chung <mandy.ch...@oracle.com> wrote:
>
>
> On 2/12/18 12:36 PM, Vitaly Davidovich wrote:
>
> 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
> than that, but that's beside the point):
> 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)
>
