Non Standadrd Module Attribute

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Non Standadrd Module Attribute

Remi Forax
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.
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 ?
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 ?

regards,
Rémi

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non Standadrd Module Attribute

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

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

-Alan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non Standadrd Module Attribute

Remi Forax
----- Mail original -----
> De: "Alan Bateman" <[hidden email]>
> À: "Remi Forax" <[hidden email]>, "jigsaw-dev" <[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non Standadrd Module Attribute

Alan Bateman
On 29/06/2017 03:04, [hidden email] 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

Loading...