Upgradeable Modules Question
ropalka at redhat.com
Wed Sep 7 12:43:16 UTC 2016
On 09/07/2016 10:32 AM, Alan Bateman wrote:
> On 07/09/2016 08:49, Richard Opalka wrote:
>> Your guess was correct Alan (my english isn't perfect).
>> Yes my distorted question was whether it should be possible to
>> "upgrade" Jigsaw module with automatic module.
> Yes, you do can do this.
Thanks for clarification.
>> Few more questions:
>> * Module java.se.ee defines list of upgradeable modules (related to
>> Is it enforced by JDK (at both compile time and runtime)
>> only upgradeable modules can be upgraded?
> It's not enforced at compile-time, there is an open issue
> (JDK-8133882) to ponder that point.
> It is enforced (by way of hashes) at link-time and run-time.
Thanks for clarification.
>> There are no other upgradeable modules except
>> those listed in java.se.ee, right?
> For the Java SE modules then that is correct. The list is of course
> something that the JSR for Java SE 9 will need to decide on. These
> APIs have always been upgradeable via the endorsed standards override
> mechanism (most have been leading a double life as standalone
> technologies too).
> There may be some other modules that are upgradeable. In the Oracle
> builds then the java.jnlp module is upgradable, as are the modules
> with Java Web Start and the Java Plugin.
>> Or one could upgrade any module not provided by Boot loader?
> None of the upgradeable modules are defined to the boot loader.
>> * Both AppClassLoader and PlatformClassLoader don't override
>> ClassLoader.getResource(String) method which fallbacks to NOOP
>> ClassLoader::findResource(String). Shouldn't they implement it?
> They implement/override findResource/findResources.
I oversaw it :(
>> I'm asking because I upgraded JAXB module locally with automatic module.
>> provided there but resourceLookup doesn't work.
> Can you provide a bit more detail as to what you are using an the
> automatic module? Ideally it would be something like:
> --upgrade-module-path eemods --add-modules java.xml.bind
That was my problem of course. I didn't activate that module (forgot
they are off by default) and
thus the jaxb-api from unnamed classpath module was used instead. There
was no JAXB impl on classpath.
Just in my upgradeable automatic module (that was off).
> but I'm guessing you might have artifacts like jaxb-api-<version>.jar,
> in which case the derived module name isn't useful.
I used exploded directory named java.xml.bind (of course without
> One thing to mention is there are changes to JAXB to work with
> modules. Those changes are in the JDK and I believe are also in the
> upstream Metro project where the RI is maintained. The MR of JSR 222
> hasn't been done yet so there isn't a released standalone version with
> the updated support. I only bring it up in case you might be running
> into issues here. AFAIK, the more significant update is the additional
> of new service type, javax.xml.bind.JAXBContextFactory and updates to
> the spec to work with ServiceLoader. At a guess then you might be
> using an old version that doesn't have any of this.
Yes, I am aware of this.
> One other thing is to ask is whether you see any difference with the
> Jigsaw EA builds. I ask because those builds don't have resource
> encapsulation, pending resolution of this issue in the JSR.
I'm testing build Jigsaw EA b134 ATM. Seems working better than previous
releases. I still see some testsuite failures (investigation goes on).
More information about the jigsaw-dev