Module compilation unit grammar

[Alex Buckley]

On 3/25/2011 11:44 AM, Jonathan Gibbons wrote:
> Statements are typically ordered.  By drawing analogy with statements, 
> are you implying that the order of the items in a module compilation 
> unit is significant and should be preserved?

I personally think it would be good if module statements were at least 
grouped in a module compilation unit, so 'require' declarations precede 
'provide' declarations etc. But there is no such requirement at this time.

Now, in a class file that is the binary representation of a module 
compilation unit, it is untestable whether the order of attributes is 
the same as the order of declarations in a module compilation unit. 
There is no compiler spec. Maybe the class file was produced 
dynamically. So there is no significance.

> Is there a spec for the compiled representation of a ModuleExport 
> statement?

This is a little tricky because it is reasonably clear that you can 
export whole packages, but the constant pool has no representation for a 
package name like it does for a class or interface name. We don't want 
to explode an exported package's members into individual exported types 
- or maybe we do. For now, I propose just treating 'export A.B.*;' as if 
it was a fully qualified class or interface name.

ModuleExport_attribute {
   u2 attribute_name_index;
   u4 attribute_length;
   u2 export_length;
   { u2 export_index; u1 flags; } export_table[export_length];
}

attribute_name_index: a CONSTANT_Utf8_info representing "ModuleExport".
attribute_length: length of attributes excluding the initial six bytes.
export_table: Each export_index points to a CONSTANT_Class_info 
representing a package or class or interface to be exported.

Alex