My position on module security/access control

[David M. Lloyd]

I wanted to summarize my position on module security and access control, 
so that all my thoughts are in one place instead of scattered across 
various threads.

The first point I want to make is that I think that the idea of having 
public classes that are not public is a red flag.  If a class and member 
is public, it should always be accessible to everyone regardless of who 
imports what module.  There should only be one access control mechanism 
in the language.  Users already seem keen to find ways to break out of 
the Jigsaw export-based restrictions and I think this is an indicator 
that, while expedient, the Jigsaw approach is far from ideal.  In 
addition I think this is an essential step towards the ultimate goal of 
removing the dreaded setAccessible() method; if frameworks cannot even 
access public members then they will never be able break away from using 
reflection as a back door.  The concept being established here is the 
ability to have a public class which is not exported but is still 
accessible to anyone.

The second point is around module privacy.  It is clear that 
(language-wise) we need an access level that is module-private.  Given 
the relative uselessness of package-private accessibility in the module 
world, I propose that any reference to a default-access-level member in 
a Java 9 class should be considered to be a module-private access, not a 
package-private access, in both javac and the JVM.  The protected access 
level should be similarly widened.  This avoids the need for changing 
the class file format or introducing new modifiers to the language or 
reflection APIs, and ensures that the language continues to have only 
one central access control mechanism, instead of two interacting 
mechanisms, and completely eliminates all the "SharedSecret"-like cases 
found throughout the JDK and elsewhere.  In the very long term, if/when 
support for Java 8-and-earlier class files is removed, only module 
access will remain, which results in a somewhat cleaner and more useful 
set of access controls.

The third point is around "friend" modules.  It seems clear that we have 
a requirement (which can be extrapolated easily from the document) that 
some modules need the ability to provide selective access to nonpublic 
members to other modules.  This requirement seems perfectly reasonable, 
and the access level change described previously should be amenable to 
this mechanism.  The mechanism could work on a package-by-package basis 
or at a module level; I think that the distinction between the two is 
relatively small in terms of implementation and is purely a user 
requirements question.  The compiler and JVM should take this 
information into account when checking access to a peer module's class. 
  The compiler will need to know, as part of compilation, what peer 
modules (or packages within peer modules) are expected to be accessible 
to the currently-compiling module at run time; the means of 
accomplishing this is a question of how the module metadata is 
represented and stored and is not directly relevant to the issue at 
hand, though I feel that a simple argument to javac/JavaCompiler is 
sufficient (i.e. let the build tool, which understands how the module is 
to be assembled and may have access to a variety of forms of metadata, 
discover the information and pass it to the compiler).

The fourth point relates to ServiceLoader.  If ServiceLoader has a 
unique and special blessing to bypass the access mechanism, then we've 
failed to design an adequately flexible (and secure) access control 
mechanism.  By implementing the three points above, ServiceLoader no 
longer needs to be a special citizen, because all service implementation 
classes are public (as they are today, and as they should be).  A user 
could implement ServiceLoader in unprivileged code and it would work 
with no special trapdoors.

My intuition is that tying exporting with accessibility hides some 
potentially serious and maybe unsolvable land mines, and recent 
discussion on the Jigsaw list seems to imply that there are more 
practical problems as well.  Keeping the concepts separate and building 
on the established accessibility mechanism seems like a much safer 
course to me (if not as expedient), and I hope I can convince the rest 
of the experts of the same.

-- 
- DML