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

[Daniel Siegmann]

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?

~Daniel