From david.lloyd at redhat.com Wed May 18 13:23:54 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 18 May 2016 08:23:54 -0500 Subject: Mutable modules Message-ID: <573C6CEA.5010105@redhat.com> Related to #MutableConfigurations, in order to support dynamically changing deployments for containers (including, I believe, OSGi-compliant containers) where deployments are modules, it is necessary to allow a module's dependency graph to be mutated at run time. The behavior of such things in existing systems is such that any already-loaded/linked dependency classes remain, thus such action is usually only guaranteed to be "safe" when adding dependencies, or when it can be somehow guaranteed that no lingering dependency classes exist, or that such lingering classes can safely be ignored. While this operation isn't 100% safe, it is supported by containers in existence today, so should at least be considered. -- - DML From forax at univ-mlv.fr Sun May 29 12:18:35 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 29 May 2016 14:18:35 +0200 (CEST) Subject: module-info.class file format In-Reply-To: <819212675.1821239.1464522495068.JavaMail.zimbra@u-pem.fr> Message-ID: <906007275.1822479.1464524315017.JavaMail.zimbra@u-pem.fr> Hi all, I've implemented the reading/writing of the class file format of a module in ASM, it was very straightforward, but let me summarize what can be improved: - the current spec only specifies the Module attribute, not how the main class or the version (by example) are specified. Moreover, these values are currently implemented as custom attributes of the class and not as attribute of the Module attribute, which seems more logical (like Code is an attribute of a Method). So currently, if ASM wants to just followed the spec, it can not provide a way for a user to specify the main class or the module version of a module. - the module name is specified as a part of a constant pool entry which is tagged as a Class [1] instead of being specified as a UTF8, like the required dependencies by example. The spec should be changed so the module name is not extracted from the class name but encoded as a UTF8 in the Module attribute. It will also make life of users of tools like ASM easier, encoding the module name as package of the module-info breaks an important invariant, the name of the resource and the name inside the .class are the same. This is not true anymore with a module-info so tools need to be updated to avoid to write module-info.class inside a package corresponding to the name of the module. cheers, R?mi [1] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4.1 From forax at univ-mlv.fr Sun May 29 21:40:09 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 29 May 2016 23:40:09 +0200 (CEST) Subject: module-info.class file format In-Reply-To: <906007275.1822479.1464524315017.JavaMail.zimbra@u-pem.fr> References: <906007275.1822479.1464524315017.JavaMail.zimbra@u-pem.fr> Message-ID: <709950336.6082.1464558009592.JavaMail.zimbra@u-pem.fr> And I've forgotten another important point, initially ACC_MODULE was thought to be used not only on classes but also on fields and methods (defining an access level). The idea to use module as a visibility modifier was lost after several iteration of jigsaw but it's value in binary 0x8000 stay the same. 0x8000 is a great value because before JDK9 the value was not defined as a possible values for a class, a method and a field. Now, using 0x8000 to specify a flag that is only valid on a class seems a waste, 0x0008, 0x0040, 0x0080, 0x0100, 0x0800 are all not defined for a class and will allow to save 0x8000 for a future use. So i propose to change ACC_MODULE for one of those value. cheers, R?mi ----- Mail original ----- > De: "Remi Forax" > ?: jpms-spec-experts at openjdk.java.net > Envoy?: Dimanche 29 Mai 2016 14:18:35 > Objet: module-info.class file format > > Hi all, > I've implemented the reading/writing of the class file format of a module in > ASM, > it was very straightforward, but let me summarize what can be improved: > > - the current spec only specifies the Module attribute, not how the main > class or the version (by example) are specified. > Moreover, these values are currently implemented as custom attributes of > the class and not as attribute of the Module attribute, > which seems more logical (like Code is an attribute of a Method). > So currently, if ASM wants to just followed the spec, it can not provide a > way for a user to specify the main class or the module version of a > module. > > - the module name is specified as a part of a constant pool entry which is > tagged as a Class [1] instead of being specified as a UTF8, like the > required dependencies by example. > The spec should be changed so the module name is not extracted from the > class name but encoded as a UTF8 in the Module attribute. > It will also make life of users of tools like ASM easier, encoding the > module name as package of the module-info breaks an important invariant, > the name of the resource and the name inside the .class are the same. This > is not true anymore with a module-info so tools need to be updated to > avoid to write module-info.class > inside a package corresponding to the name of the module. > > cheers, > R?mi > > [1] https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4.1 >