[jsr294-modularity-eg] Scope

[Alex Buckley]

// BJ, please read, there's a question for you at the end!

Peter,

The links you gave are rather out of date. Superpackages are so 2007!

I clearly placed visibility in scope when 294 restarted in 2009 [1] [2] 
[3]. BJ commented at the time [4] 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 
requirement 6:

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 [5] dealt primarily with module membership 
(where we all now agree) and made only the slightest passing reference 
to dependencies.

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?

Alex

[1]http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-January/000184.html
[2]http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-January/000186.html
[3]http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-January/000187.html
[4]http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-February/000211.html
[5]http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-February/000213.html

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. [1]
> 
> 
> 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 official part of the Java SE 7 Platform
>     Specification and might not be supported by other SE 7
>     implementations. [1]
> 
> 
> And one only has to read [2], 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 [3], and [4] 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
> 
> [1] http://blogs.sun.com/mr/entry/jigsaw
> [2] http://blogs.sun.com/gbracha/entry/developing_modules_for_development
> [3] http://blogs.sun.com/andreas/entry/superpackages_in_jsr_294
> [4] 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
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg