peter.kriens at aqute.biz
Thu Jul 16 04:19:00 EDT 2009
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
From a pure OSGi perspective putting a meta-module system in the
compiler would have its advantages because we ould do all kinds of
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 :-)
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.
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-eg