Non Standadrd Module Attribute

forax at univ-mlv.fr forax at univ-mlv.fr
Thu Jun 29 02:04:29 UTC 2017


----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoyé: Mercredi 28 Juin 2017 14:22:23
> Objet: Re: Non Standadrd Module Attribute

> On 28/06/2017 12:12, Remi Forax wrote:
>> Hi Alan, hi all,
>> i've implemented the non standard attributes ModuleTarget, ModuleHashes and
>> ModuleResolution in ASM.
>>
>> First, given that i was not able to find a document that describe them, i've
>> used the javadoc of the classes inside jdk.internal.module.ClassFileAttributes.
> JEP 261 needs a big update and I think is the right place to document
> the JDK-specific class file attributes (except maybe ModuleResolution
> where they could be a case to document it in JEP 11 instead).
> 
>> I've discovered that the jdk modules have an attribute ModuleTarget that can
>> have a null platform, why not removing the ModuleTarget attribute from the
>> module-info instead ?
> The ModuleTarget attribute is removed at link time from all modules
> except java.base (need to retain it in java.base to allow it be compared
> with any platform specific modules on the module path). The jlink system
> modules plugin has an option to retain the ModuleTarget attribute if you
> want.
> 
> As regards allowing the target_platform to be 0 (meaning not present)
> then it may be a left over from when the attribute had multiple values -
> it was possible for it to only have the OS name or architecture for example.

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.

> 
>> And for the module jdk.incubator.httpclient, the value of the resolution is 9,
>> so it means DO_NOT_RESOLVE_BY_DEFAULT | WARN_INCUBATING;
>> What is the exact meaning of DO_NOT_RESOLVE_BY_DEFAULT ?
>>
> 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 ? 

> 
> -Alan

Rémi


More information about the jigsaw-dev mailing list