[jsr294-modularity-eg] Pain

[Peter Kriens]

What I am saying is that the JLS needs to define what a module is, and  
I sketched a possible model provided enough leeway for module systems  
to provide additional functionality; it is not my dream model as you  
seem to interpret it. Maybe I failed, but I think the goal is worthy.

In the container sketch, I attempt to move the choice for a module  
system out of the JLS, which I do by defining the module as a language  
construct, which is what I hear many people want. Something like  
packages but with higher granularity. Containers introduce the (more  
messy) runtime aspects. The sketch tries to define containers in such  
a way that match the language modules, and then defines visibility  
rules that I thought we might be able to agree upon so the compiler  
does not have to know the actual module system when compiling Java  
source code.

 From a pure OSGi perspective putting a meta-module system in the  
compiler would have its advantages because we ould do all kinds of  
clever things.

However, I am not talking here as an OSGi guy, I am standing here in  
front of you as a Java programmer. The idea that in the future we will  
have as many variations of Java as there are module system is highly  
disturbing to me. Even if there would only be two, this would already  
make the life of developers a lot harder and thereby significantly  
reduce the value of Java.

It is kind of interesting how Gilad Bracha did not want the deployment  
guys to touch the language, that's why he started 294. I think I  
understand now what he meant :-)

Kind regards,

	Peter Kriens


On 15 jul 2009, at 19:26, Alex Buckley wrote:

> Peter Kriens wrote:
>> The core issue I am raising is that we make the Java language  
>> depend on the module system, which is fundamentally wrong.
>
> And yet the first line of your sketch is: "In the JLS we define a  
> clean concept of module". You go on to define module imports,  
> implementation-v-specification APIs (I thought that split was  
> deprecated in OSGi?), module containers, and module repositories.  
> Looks like the Java language would be deeply tied to an abstract  
> module system in the style of 277.
>
> Alex
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg