[jsr294-modularity-eg] Pain

[Peter Kriens]

Again, the sketch I made is trying to come up with a proposal that  
took all our conversations into account. It is not my dream model but  
something that I think we could agree to prevent fragmenting the Java  
language by giving each module system its own "Java".

Anyway, I think your confusion is related to the dichotomy between  
deployment modules (which I will refer to as the container from now  
on) and the language modules.

Container membership (internal keyword in .NET) should not be encoded  
in the source because it I think that we can provide many useful  
functions in creating the container and packaging it in different  
ways; encoding the membership in the code would make this much harder  
than necessary. That is, using the module keyword in source without a  
module has the scope of the container. It will also allow a project to  
be packaged in a container without a lot of work.

However, namespace modules (namespaces in .NET) which are a  
hierarchical grouping of packages have a much smaller granularity and  
are what packages always implied but were not: hierarchical. I still  
do like the idea of making module membership depend on the position of  
module-info because it is a non-redundant approach. However, something  
that is so close to packages feels a bit odd to not mention it in the  
source code. Mentioning the module is more in the spirit of Java where  
a compilation unit is completely contained:

	module com.acme.foo;
	package main;
	class Main {}

For type com.acme.foo.main.Main, this feels pretty natural. This  
proposal also seems to reflect the nature of modules in Ruby, .NET,  
Modula-2, etc. And the gap between this model and the current package  
based model in the JLS is surprisingly small, usually a good sign.

In the sketch, I made a clear distinction between container-info.java  
and container-info.class ... The compiler compiles the source code  
into class files and another tool creates container-info.class by  
aggregating the information in the source class files. It is likely  
that we have a module system dependency but maybe, if we try hard, we  
could make this generic! The indirection of not compiling but  
aggregating makes it possible to specify a broad palette in the  
container-info.java source file while only encoding the real  
dependencies in the container, as well as aggregating the visibility  
rules, making it easy for the compiler and runtime to use the  
container. The broad palette is very useful during development because  
it allows easy completion.

To summarize: I am AGAINST container membership in source but I am  
currently slightly in FAVOR of namespace module membership in source.  
But if you want to convince me of the proposal to make module  
membership depend on the package that contains a module-info file,  
then lets talk! The only thing I want at this moment is a JLS that  
does not let the Java semantics depend on a pluggable module system ...

Kind regards,

	Peter Kriens

P.S. The fact I objected to 277 and 294 super packages was not because  
the core ideas were bad,. Obviously, our industry is blessed with a  
rather high average IQ and many ideas people propose are quite good.  
My opposition was caused because the actual execution of many of those  
ideas, and mainly because they did not take some perspectives into  
account.

P.P.S. I am not sure why it would be bad if I had contradicted myself  
in old mails, after talking for 6 months in this EG? Aren't we all  
going through a learning process? Isn't that one of the goals of a  
good EG?




On 16 jul 2009, at 20:03, Alex Buckley wrote:

> 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
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-eg/attachments/20090717/01d5b844/attachment.html>