Proposal: #FixClassFileFormat

[mark.reinhold at oracle.com]

2016/7/1 0:39:00 -0700, Remi Forax <forax at univ-mlv.fr>:
> mark.reinhold at oracle.com:
>> 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
>   encoded at 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.

On this last point: They should be specified, and will be specified in
an upcoming revision to the spec.

Before digging into the other two issues I'd like to try just to record
them, without any bias toward a particular solution, so I'll add the
following two items to the issue list:

  #ClassFileModuleName --- The name of a module is not a simple UTF-8
  string but is, rather, derived from the `this_class` field of the
  `ClassFile` structure, which is awkward.

  #ClassFileRequires --- The `ACC_PUBLIC` constant in a `requires_flags`
  should be encoded as `0x0001`, as it is elsewhere in the JVMS, rather
  than as `0x0020`, which has different meanings in other contexts.

- Mark