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-.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
