Non Standadrd Module Attribute

[Alan Bateman]

On 29/06/2017 03:04, forax at 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