[jsr294-modularity-eg] Pain

[Alex Buckley]

Peter Kriens wrote:
> The consequence of the current JSR 294 design is that the JLS is not 
> sufficient to understand a set of source files because it does not 
> define module membership.
> 
> This is acceptable for you?

Peter, you argued in February AGAINST module membership in source and 
class files:

"Peter's idea is further that only module-info.class would have a Module
attribute giving module membership. Normal classfiles would have
membership determined at compile-time based on their nearest enclosing
module-info.java/class, and at runtime based on a module system calling
defineClass(..., moduleID)." [1]

Also, in your proposal, container-info is a compile-time list of 
dependencies, but in March, you argued AGAINST that:

"Peter did not support declaring dependencies in source at all. Claim:
having to list dependencies upfront is unnecessarily constraining;
programmers should have a broad palette of packages available to them
during development (e.g. for code completion in an IDE); a build-time
step should determines actual dependencies from classfiles and reify
those dependencies in the artifact." [2]

I don't understand why you are suddenly so keen to put module identities 
and dependencies into source, when you have been against it for the past 
six months.

Alex

P.S. Your augmented package-info file reminds me of a superpackage - a 
central file that changes the meaning of 'public' in other compilation 
units - but that's another topic.

[1]http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-February/000217.html
[2]http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-March/000222.html