[jsr294-modularity-eg] Pain

[Alex Buckley]

Thanks, this is clearer for me now. You've differentiated container 
modules (and the processing of container-info.*) from namespace modules, 
so you're technically consistent. Even if you weren't, let us recall 
John Maynard Keynes: "When the facts change, I change my mind. What do 
you do, sir?"

Namespaces in .NET are a hierarchical program structuring feature, 
orthogonal to access control. You describe in namespace modules a 
hierarchical program structuring feature that is a) more complex than 
namespaces (due to imports in package-info) and b) deeply involved with 
access control (due to 'import implementation module ...' and 
module-level accessibility following the hierarchy). This is clearly 
outside the design space covered by .NET, so there is no point alluding 
to .NET's cleanliness.

Regarding container-info.java and container-info.class as described 
below, they are outside the scope of a JSR. The 294 spec cannot mandate 
the existence of tools and the operational steps of a build process.

There is also the fact that 294 aims to align the compile-time 
environment with the runtime environment. I can't tell if 
container-info.txt is meant to be read by a compiler *for the purpose of 
setting up a classpath*. Based on your belief in a "broad palette", I 
guess you still require people to set the classpath, and then have the 
optimized container-info.class hold the minimal classpath for runtime. 
If that's the case, then no way - the classpath is going. If that's not 
the case, and container-info.txt IS meant to auto-configure the 
classpath at compile-time, then I don't see why delaying production of 
container-info.class is such a big deal. My compiler emits a 
module-info.class that tools can optimize w.r.t. classfiles as they wish 
- 294 doesn't need to know.

I'm not in favor of this proposal and it's far from clear that the 
Expert Group as a whole is in favor. Rather than inventing arbitrary new 
language features, we should try to standardize directives within a 
module declaration as far as possible, as Bryan said.

Alex

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