[jsr294-modularity-eg] 294 EG conf call, 2009-04-08

[Alex Buckley]

Roman Elizarov wrote:
> AB> Finding module-info is easy when each package becomes a module,
> AB> but that's not the common case. The common case is multiple
> AB> packages joining a module.
> 
> I belive that the most common case is the opposite -- a single package
> will become a module in the majority of cases, since most libraries
> are simple.

The common case is compiling a single module, containing one or many 
packages:

src/classes/module-info.java   ***NEW***
            /com/foo/bar/Quux.java
            ... and rest of module

If module-info isn't "shallow" (i.e. in the root), then it has to go 
deep, but how deep? I showed that complex package hierarchies cause the 
location of module-info to become difficult to determine, unless you 
have module membership is needed in source. That is not going to happen, 
so deep module-info doesn't work. Making it shallow, in the root, is 
good for clarity anyway.

Compiling multiple modules together needs a different directory 
structure, end of story. (Again, without module membership in source, 
deep module-info's are unworkable.)

> AB> As for module names, we don't know how they will be structured.
> AB> Linux distros cope quite well with short names (+versions) for
> AB> rpm/deb files.
> 
> They do. But I belive that this is a bad naming practice and should be
> discouraged. We don't need yet another names space and naming
> convention for modules. When I use a library, why do I have to
> remember an additional piece of information (its module name) in
> addition to its package name? When we are talking about "language
> modules" we (language designers) should impose or suggest the naming
> convention to the users of that language. If we don't know how they
> will be structured, then we probably should not make it a language
> feature. Leave it out of the language and stick with deployment-only
> modules, then.

Language-only modules (used for accessibility but not visibility) don't 
get rid of JAR hell.

Deployment-only modules (used for visibility but not accessibility) 
don't provide proper encapsulation.

294 aims to sit in the middle, and the ongoing EG discussions help to 
determine where precisely the middle is.

No doubt there will be suggested conventions for module names. But while 
the package name convention was present at the dawn of time and so is 
universally followed, a module name convention is likely to enjoy weaker 
support. As you say, there's just too much code out there already in a 
pseudo-modular structure, and I want 294 to work with it.

> AB> A non-answer is "module membership in A.java and B.java", since
> AB> the EG has clearly expressed its opposition to that. Another
> AB> non-answer is "a command-line switch", since that means only one
> AB> module at a time can be compiled.
> 
> What is the problem with "package declares module membership in its
> package-info" approach?

Module membership in package-info.java/class was a shorthand for module 
membership in normal source files. Normal classfiles were going to 
remember their module membership, that's what the EG didn't like. Are 
you proposing ONLY package-info.java/class contain module membership? In 
fact, don't tell me an idea - I hear lots of those already. Write 
something up in detail.

Alex