On 29/06/2017 03:04, fo...@univ-mlv.fr wrote:
:
yes, it's what i'm believing too.
To take an example, currently, the module-info of java.sql as n attribute
ModuleTarget which is empty, IMO only java.base should have a module attribute
ModuleTarget.
Okay, I understand what you are saying now. When the jlink plugin
re-writes the module-info.class in the jimage file then it amounts to
changing the target_platform_index to 0 rather than removing the
ModuleTarget attribute completely. This is benign because the system
ModuleFinder doesn't parse module-info.class resources in the image, and
if it did, it tolerates the target_platform_index being 0. I'm guessing
you see it because you are reading the module-info.class in the jimage
container.
:
From JEP 11 "incubator modules are not resolved by default for
applications on the class path".
in that case why java.xml.bind which is not resolved by default too, does not
have an attribute ModuleResolution ?
The policy in JEP 261 for the default set of root modules pre-dates this
attribute. Yes, it would be possible to implement that policy (or a
slight variation of) using this attribute although it would introduce a
small inconsistency for the upgrade module path, say where you deployed
an upgraded version of java.xml.bind that didn't have the attribute -
would you want that to be resolved because it exports an API?
-Alan
