Alex.Buckley at Sun.COM
Fri Apr 24 02:29:29 EDT 2009
// BJ, please read, there's a question for you at the end!
The links you gave are rather out of date. Superpackages are so 2007!
I clearly placed visibility in scope when 294 restarted in 2009  
. BJ commented at the time  on how some requirements described
properties of a module system and were therefore outside the scope of
294; I promised to remove them and the corresponding language
constructs. But I do not recall BJ arguing specifically against
6. A module must be able to declare dependencies on other modules, by
specifying their identities in the Java language. ...
BJ's other mail at the time  dealt primarily with module membership
(where we all now agree) and made only the slightest passing reference
Certainly, Peter, the EG minutes show you have led the charge against
dependencies in source. But perhaps I have underestimated BJ's concern
about visibility, and he believes it should not be in scope?
Peter Kriens wrote:
> As a matter of order, I'm having a bit of problem where we are ending up
> in the JSR 294 effort.
> I made it very clear before we started that I was interested in the
> accessibility aspects of JSR 294; I fully supported Richard's proposal
> to focus on that hard nut instead of visibility. My motivation was
> mainly driven by Mark Reinhold's promise:
> ... Sun plans now to work directly with the OSGi Alliance so that a
> future version of the OSGi Framework may fully leverage the features
> of JSR 294 and thereby achieve tighter integration with the
> language. 
> However, we seem now to have ended up at attempting to develop a module
> system in the Java language that happens to be Jigsaw in disguise. This
> is neither in the original scope of Jigsaw, nor JSR 294. To quote Mark
> Reinhold on Jigsaw (underlining mine):
> This effort will, of necessity, create a simple, low-level module
> system whose design will be focused narrowly upon the goal of
> modularizing the JDK. This module system will be available for
> developers to use in their own code, and will be fully supported by
> Sun, but it will not be an ofﬁcial part of the Java SE 7 Platform
> Speciﬁcation and might not be supported by other SE 7
> implementations. 
> And one only has to read , the superpackages blog that founded JSR
> 294, that JSR 294 was focused on accessibility and left the visibility
> to JSR 277. This was confirmed in , and  from Alex when he
> introduced the module keyword.
> Let's face it, defining the semantics of the module keyword already
> seems a daunting task enough, but at least achievable.
> Kind regards,
> Peter Kriens
>  http://blogs.sun.com/mr/entry/jigsaw
>  http://blogs.sun.com/gbracha/entry/developing_modules_for_development
>  http://blogs.sun.com/andreas/entry/superpackages_in_jsr_294
>  http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2008-March/000171.html
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-observer