[jsr294-modularity-eg] Pain

[Richard S. Hall]

I sent this response on July 16th, but it didn't get through because I 
sent it from the wrong account I guess. I am resending it for the 
record...see below...

On 7/15/09 7:39 PM, 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.

It seems somewhat defeatist to just resign ourselves to the fact that we 
need a design-by-committee, meta-ish approach. I agree with Peter's 
overall goal of trying to be more concrete. The trick is keeping it 
small, while leaving room for module systems to do their own thing.

 From what I understand about Peter's proposal, he suggests agreeing upon:

    * Defining packages to be either public, module, or private.
    * Defining dependencies to be either "normal" or "implementation"
      (where module-level dependencies are mapped down to package
      dependencies)
          o "normal" sees only public types in public packages.
          o "implementation" sees public and module types in public or
            module packages.

I think this sounds reasonable.

The "hook" for module systems is when the container is created, the 
various module systems can map the above constructs into their own 
approach, which can have their own ugly semantics as far as things like 
class loaders are concerned (e.g., whether it is loaded by different 
class loaders or the same, the actual search policy, etc.).

The important point, is the logical relationship definition would be the 
same, the only thing that would be different is specific run-time 
aspects of the module systems.

-> richard

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090722/ec929f20/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