Proposal: #FixClassFileFormat

[Remi Forax]

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: jpms-spec-experts at openjdk.java.net
> Envoyé: Jeudi 30 Juin 2016 02:35:59
> Objet: Re: Proposal: #ReflectiveAccessToNonExportedTypes: `exports dynamic`
> 
> 2016/6/29 1:51:16 -0700, Remi Forax <forax at univ-mlv.fr>:
> > I would like to agree on that proposal only on the ground that it
> > requires to change the classfile format thus allows in the same time
> > to fix the issues of the current classfile spec (encoding of the name
> > module as a Class instead of UTF8, wrong flag for requires public),
> 
> I think that these are completely distinct issues (though your
> class-file issues are not yet in the issue list -- would you care
> to suggest some text?).

yes, sure.

when implementing the support of module into ASM, i've discovered several issues in the classfile format as defined by [1]
- module name is not encoded as UTF8.
  The spec makes great cares to encode reference to module in 'requires' by example as "UTF8" constant pool entry, a name with no other constraints, but fail to do the same thing for the name of the module itself.
  The name of the module is derived from the name of the class which is encoded as a "Class" constant pool entry. The way to solve that is to avoid to derive the name of the module from the class, the name of the class should be module-info, with no package, which seems logical given that the source file is module-info.java (not prefixed by a package) and the name of the module should be encodedat the beginning of the "Module" attribute as a reference to the constant pool entry of type UTF8. This format can also be more compact despite adding two bytes in the "Module" attribute in the fairly common case where one exported package as the same name as the module name because of the constant poll sharing the names.

- there is what i believe is a typo in the current spec when specifying the modifier of a required module (requires_flags), the modifier ACC_PUBLIC is said to have the value 0x0020 instead of 0x0001 in the JVM spec. (0x0020 is either ACC_SUPER or ACC_SYNCHRONIZED).

- the attributes for specifying the main-class, the module-version, a concealed module, etc are not specified, and i don't know if there is a reason to not specifying them. 

Rémi

[1] http://cr.openjdk.java.net/~mr/jigsaw/spec/lang-vm.html