[jsr294-modularity-eg] Pain

[Doug Lea]

Peter Kriens wrote:
> 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.
> 


Sorry for the delay in responding to this and related mail --
I was out for 2 weeks.

Catching up now, I think my main reaction is similar to Bryan's,
but I'll step back a bit explaining.

We are grafting module support into an existing language
that had none. Which means that it will necessarily have
properties more like a "framework" than it might have if
we were doing language design from scratch. Further, it
will necessarily have a bit of a design-by-committee feel,
because of the long and diverse experience people have
accumulated living without language-based support.
None of this seems tantamount to agreeing to "go our own way",
but rather accommodating as many good practices as possible
while avoiding known pitfalls.

I suppose it could have been otherwise. For example, if
by historical accident OSGi had initially had some form
of protected-access conventions, we might not have gotten stuck
over them. This and only a few other consensus failures
force declaring the meta-ish approach of defining module systems
rather than modules. But as Bryan has noted,
providing required flexibility about other matters forces
us to accommodate some degree of plug-in support somewhere, so we
might as well leave it at the top level. I'm basically content
with that decision, if for no other reason that if someone
someday dreams up The Ulitmate Module System people can start
using it without a 3+ year standardization lag.

Thus, I'm not too excited about your alternative sketch.
Although like Bryan, I do hold out some hope that the
specs for directives such as "requires" that seem intrinsic
to any module system can be made tighter. At the very least,
this mail thread should motivate us (well, mostly Alex :-)
to push harder on identifying those features that can be
spec'ed in a module-system-independent manner.

> 
> 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 ...
> 

Sorry that I don't get this part. Various existing module-like
support mechanics are the very essence of
"messy and complex runtime worlds" that most people can cope
with only by using automation tools. Some of us worry that these
people are not actually programming in Java, but instead in an
IDE with a few dozen semantics-altering plugins, none of which
have language-quality specs.

-Doug