Upgradeable Modules Question

[Richard Opalka]

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 
>> EE).
>>    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.
ok
>
>
>>    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.
>> There's
>>
>> META-INF/services/javax.xml.bind.JAXBContext
>>
>> 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 
module-info.class).
>
> 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).
>
> -Alan
>
Richard