[jsr294-modularity-eg] Pain

[Peter Kriens]

> 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.
Though I do agree JSR 294 does not mandate tools, it does define  
concepts that are reified by tools. I.e. the javac compiler is implied  
by the compilation unit.

Therefore, I fail to see why we could not (and I actually strongly  
recommend it) define a container unit in the JLS that is reified by  
some other tool than javac?

Kind regards,

	Peter Kriens


On 18 jul 2009, at 05:17, Alex Buckley wrote:

> 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
> _______________________________________________
> jsr294-modularity-eg mailing list
> 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