module-info.class spec and attributes

[Alex Buckley]

Hi Peter,

Thanks for casting your eye over it.

On 6/29/2011 2:33 AM, Peter Kriens wrote:
> There seems to be quite a bit of redundancy (and thus complexity) in
> this structure because it allows * relations between the flags
> (provide,require,permit,module) that designate a ModuleId_Info
> struct. I.e. the proposal allows me to require/permit/provide the
> same module multiple times. Even though this is not allowed with an
> extraneous constraint this seems inefficient design, why create the
> opportunity for errors?  It seems that provide/require/permit/module
> could easily be a handled with an enumeration or bitset: {
> THIS_MODULE, PROVIDE, PERMIT, REQUIRE_OPTIONAL, REQUIRE_FRAGMENT} in
> the ModuleId_Info struct?  The use of attributes to set a bit seems
> overkill and will require unnecessary constraints on the cardinality
> of these attributes, making processing this file in tools harder.

You'd still need a constraint that a (module id, enum value) pair must 
be unique. Would that be extraneous too?

The use of multiple attributes is verbose, sure, but it's convenient for 
prototyping.

> Similar about the redundancy in the module name. The module name is
> both the this_class package name as well as defined in the
> ModuleId_Info struct?

The reason for this is noted in the first section: there is 
conventionally a mapping between pathname and this_class. The tiny 
duplication is really not a big deal.

> Interestingly the model allows package export (though unfortunately
> not import, one should always wonder why things are not symmetric,
> but I guess that is another discussion). However, class exports can
> be top levels only (I assume no nested classes?) and recursively.
> However, packages are top level classes in the designated package and
> the all subpackages. This seems to miss the cases for nested classes
> in the single package and nested classes in the sub-packages?

There is nothing limiting an export to a top level class. "If you can 
name it, you can export it."

(I should have said that exported entities are identified by binary 
names, extended to allow package names, which have canonical names but 
not binary names today.)

Not sure what you mean by "packages are top level classes in the 
designated package". Both 0x04 and 0x08 for package export include 
nested classes, in the same package and in subpackages respectively.

> I am a bit confused about the scope of the module as this is not
> defined. I.e. a class defines all its members, not just the public
> ones. Shouldn't a module also define its private members?

Since "private" (i.e. non-exported) classes are not visible from outside 
the module, what difference would enumerating them make?

> Obviously the extension model is a bit of a joke, all we get is a
> list of unadorned strings per module? The minimum that is needed is a
> model that allows the exports, provides, permits, and module
> attributes to be annotated in an elegant way. For example,
> ModuleClass is clearly a Jigsaw extension and several of the bit
> fields are also highly semantic, such semantics should be extensible
> as it is very unlikely you get it right the first time. Why not model
> these with an extension model and eat your own dog food?

The attributes follow the requirements of the Java Module System. 
ModuleData is for content in a module declaration that is outside those 
requirements. Regarding ModuleClass, it's a placeholder until there's a 
requirement that addresses entrypoints.

> Treating packages as members of a module and imports as references to
> other modules would make the class file a very good fit; every Java
> developer would immediately see the symmetry and have an intuitive
> understanding.

Package imports are an open requirement 
(http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12#package-level-dependences) 
so are not addressed here.

> As the current proposal has no affinity to a class file format
> whatsoever; it seems wrong to abuse the class file format just
> because it happens to support attributes. There are better formats
> for this purpose, formats that could also allow some human
> readability for debugging and easy annotation by third parties
> without requiring class format changes for every new module concept.
> Obviously XML is the most powerful and best suited format for this
> problem. The JLS module specification can just as easy output to XML
> as attributes in a class file but will be significantly easier to
> handle in most  environments and will not require an upgrade in class
> version for every minor change.

Let's not argue about syntax ad infinitum. The big picture is that the 
Java Module System will define a fixed set of "module concepts", as you 
put it, whose semantics evolve at the pace of Java SE. New SE, new 
classfile version, new module system constructs. Tools will evolve to 
manage those constructs, as they do today for new language, VM, and API 
features. For example, javadoc will render module dependencies.

Alex