Module accessibility (was: Project Jigsaw: The Big Picture (part 1))

[Jesse Glick]

On 12/21/2011 09:29 PM, David M. Lloyd wrote:
> 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

For code targeted to 8+ and not using any (nondefault) views, I like this a lot:

1. "public" would mean what it says - to javac, to javadoc, to java; and most importantly, to someone reading an individual source file.

2. Refactoring implementation code inside a module into (or out of, or across) nested packages for clarity would become simpler because you would not need to fiddle with 
modifiers - all the impl code would use default access regardless of package location (keeping the code shorter too), with the obvious exception of overridden public methods.

3. The well-known problem of adding an internal-only method (called from other packages) to an exported class would disappear - just use default access. (In current 
Jigsaw I think you have to work around this by adding an unexported type in the exported package which delegates to a default-access method; in systems which only allow 
whole packages to be exported, the workaround is more intricate, involving a callback in a nonexported package and static initializers.)

4. The module-info.java semantics could permit you to omit "exports" clauses, or perhaps explicitly says "exports *", to mean that any class in any package should be 
accessible iff it is marked public. This avoids the bottleneck of editing module-info.java every time you place a new package into the API (thus risking merge conflicts 
in an SCM etc.).

If you are using views to export certain packages to certain callers only, then I guess module-info.java could use explicit "exports" clauses as in the current proposal, 
while still taking advantage of #3 and perhaps #2.

> 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.

They would still work, but you may want to ban outside access to implementation packages despite their containing public members. For this case also, an explicit list of 
"exports" clauses would work if recompiling with -source 8 or using 'jar uvf *.jar module-info.class'.