[jsr294-modularity-eg] Pain

[Peter Kriens]

As you probably have noticed, I am not very happy where we are.  
Instead of providing a singular model based on best practices, we  
worsen the situation by introducing the world's first meta module  
system that is completely outside whatever we already have in Java.  
And while we're at it, we're not fixing any of the known deficiencies.

Alas, we are not standardizing Java modules, we are agreeing to go our  
own way.

We are not reusing any Java concepts, the complete definition of  
module is left to the module system. And sadly, Java has modules, they  
were called packages. As the JLS says: "Chapter 7 describes the  
structure of a  program, which is organized into packages similar to  
the modules of Modula." In 294, instead of building on the existing  
Java Language constructs and fixing its shortcomings, we went off on  
something that is a hybrid of .NET's namespace and assemblies. I  
invariably notice that when 294 is discussed people are in the ".NET  
namespace/Ruby modules" world or in the ".NET assembly/Ruby gems"  
world, it is rare that I feel that the subtle distinctions and overlap  
in concepts is clearly understood. Hey, I am not even sure I get it.  
At the same time, each camp seems to have a clear view what it will  
get out of 294. Which I guess over time they will when a cotton  
industry of module systems has arisen, but in a Java world where the  
word Java is no longer sufficient to define the language.

Module is a well defined word but it is fractal. A code block is a  
module, method is a module, a class is a module, a package is a  
module, a library is a module, and a program is a module. They all  
have an inside and an outside, where different rules apply. My problem  
with the current design is that it does not define anything that fits  
nicely in this hierarchy or even resembles existing Java concepts; it  
will leave details up to the module system. This will make the source  
code no longer portable, the antithesis of Java :-( Yes, I can see  
lots of cool features we can provide with the Eclipse compiler and the  
OSGi runtime but it saddens me that this will fragment the Java world,  
forcing the user to find out the features that are portable between  
module systems or committing to their favorite module system.

In Java 1..6 the language offered a pretty pure model that was mapped  
to reality in the VM. With class loader tricks we could tweak the  
perspective each JAR had of this pure world, solving many real world  
problems. In JSR 294, we will for the first time introduce this messy  
and complex runtime world in the language. Untold millions have been  
spent to make Java run on hundreds of platforms, and with one simple  
JSR we bring back the need for #ifdef ...

Kind regards,

	Peter Kriens



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090709/def125a8/attachment.html>
-------------- next part --------------
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg