[jsr294-modularity-eg] Pain

[Peter Kriens]

Doug,
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?

Kind regards,

	Peter Kriens





On 16 jul 2009, at 01:39, Doug Lea wrote:

> 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
>
>
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg