DRAFT: Project Jigsaw: The Big Picture (part 1)

[David M. Lloyd]

On 12/21/2011 07:56 PM, Daniel Siegmann wrote:
> On Wed, Dec 21, 2011 at 4:29 PM,<mark.reinhold at oracle.com>  wrote:
>> 2011/12/21 1:31 -0800, julien.ponge at gmail.com:
>>> I always felt like it was weird to have public classes that in reality are not
>>> being made visible at the package level. In OSGi this leads to JARs / bundles /
>>> modules that have public types not being really public depending on the runtime
>>> context (classpath, OSGi, etc).
>>>
>>> Why not rely on the compilation unit visibility? Like introducing a "module
>>> protected visibility" without managing it at the module metadata level? I tend
>>> to think that "module protected class Foo { }" is cleaner than "public class
>>> Foo { }" only to be made "hidden" in module-info.java by not having a
>>> corresponding exports clause.
>>
>> We've considered that.  If we were starting from scratch today, such a
>> general module-accessibility modifier could well be the way to go.  With
>> countless lines of existing Java code out in the wild, however, our take
>> is that if developers have to modify all their source code and rebuild
>> their libraries and systems in order to take advantage of modularity (or,
>> equivalently but less robustly, run tools over their existing binaries),
>> then that would be a significant barrier to adoption.
>
> This doesn't seem a very good justification to me. It is likely this
> system will be in place for a very long time, and eventually the
> amount of new code being written for JDK 8 and later will outweigh the
> legacy code.
>
> Why not support both approaches? A "module protected" visibility could
> be added and could be the recommended approach for new code which
> targets JDK 8 or later. Meanwhile, the visibility of public types
> could default to being visible outside the module, but could be
> restricted by package in module-info.java.
>
> Or am I overlooking something?

Be sure you're not confusing visibility with accessibility.  I think 
Mark was talking about accessibility - you seem to be talking about 
both.  All the major module implementations seem to implement visibility 
in terms of packages primarily, and classes secondarily if at all, so 
it's not perfectly clear how the accessibility of a class can apply to 
its visibility.

As far as accessibility goes, I still believe that the a simple approach 
is best:  Expand package/default access or protected access (or both) to 
mean "module-wide" instead of "package-wide" if the source/class file 
version is Java 8 or later (this can be done a number of ways; it is not 
my intent to expand on these details at this point though I do have a 
few ideas).  Because the accessibility setting is already confined to a 
module there's no need to retroactively change source code.  The package 
accessibility limit is not meaningful when a package is confined to a 
single module (as it very definitely should be) so this becomes 
conceptual dead weight post Java 8 anyways.  Why not clean up the trash 
while adding a new concept in an intuitive way?

This way you don't have to change a single line of code to take 
advantage of the feature... indeed you don't even have to take advantage 
of the feature at all if you're just repackaging old class files because 
they obviously already work with the more constrained visibility that 
they originally shipped with.

-- 
- DML