Proposal (revised^2): #ReflectiveAccessToNonExportedTypes & #AwkwardStrongEncapsulation: Open modules & open packages

[mark.reinhold at oracle.com]

2016/11/1 14:17:43 -0700, neil.bartlett at paremus.com:
> ...
> 
> With regards to this latest proposal for
> #ReflectiveAccessToNonExportedTypes, it is certainly better than the
> previous proposal (weak modules). However I find myself wondering
> whether “open” should be the default? I anticipate use-cases in which
> a module author cannot predict whether or how the module will be
> accessed reflectively — in this case she would not have used the open
> modifier and reflection will not be possible.

As noted near the end, the proposal primarily addresses "friendly" uses
of reflection, in which a module's author is aware (perhaps with help
from an IDE) of which modules or packages need to be open for deep
access by reflective frameworks.  In scenarios where a module's author
can't foresee the need for such access (e.g., intrusive serialization
frameworks) then the framework's author must take more drastic measures
(e.g., use the legacy unsupported unsafe API).  This balance is intended
to help maintain the integrity of a module as expressed by its author.

>                                               In fact I believe that
> most module authors will open everything as a shortcut to
> compatibility with existing frameworks.

That may be true, at least in the near-to-medium term, but I wouldn't
consider it a failure.

> For example, DI frameworks such as Spring or CDI perform classpath
> scanning to find annotated bean types. Web containers scan for
> annotated Servlets or JAX-RS Resource classes. It may be hard for
> developers using these framework to find the minimal set of packages
> or modules to open.

If a framework uses annotations then the presence of those annotations
can help identify which packages (or entire modules) need to be open.
We could formalize this by defining a meta-annotation which can be
applied to a framework annotation in order to indicate that a package
containing an element upon which that annotation is used is expected to
be open, as previously suggested [1][2].  IDEs and other tools could
interpret this annotation and offer to insert the necessary `opens`
directives in the relevant module declaration, or even make the entire
module `open`.

Do you think such a meta-annotation would be worthwhile?

>                     There may be a small number of utility packages
> that can be closed, but wouldn't it be easier to explicitly close just
> those?
> 
> By analogy with other levels in the Java language: classes are not
> final by default, and packages are not sealed by default.

In my view these two points are, in retrospect, flaws in the original
design of the language.  That classes are not final by default has
resulted in all sorts of gratuitous subclassing and, worse, some fairly
nasty compatibility issues -- not least in Java itself!  That packages
are not sealed by default has resulted in split packages, whether
intentional or not, and all the pain that they bring.

Based upon our long-term experience with those decisions, I strongly
suspect that if modules are open by default then most developers will
define them that way at the start and never think about it again.  If,
on the other hand, they have to type `opens` to open a package or `open
module` to open an entire module then it will be readily apparent that
they're allowing additional access, which in turn will hopefully motivate
them to think further about whether that's the right thing.  Sometimes it
is, and sometimes it isn't.

> Finally, in the notes section of your proposal you recognise that it
> will be common to have open modules. However in the main text there is
> still some of the language about open modules being a migration step
> towards “normal” modules, which is reminiscent of your earlier
> characterisation of weak modules. My concern with weak modules was
> that they could never be fully eliminated, so it was wrong to talk
> about them as purely transitional. Do you agree that there are valid
> use-cases in which even a well-modularised application contains a
> number of open modules?

Yes, absolutely.  Some modules will be open forever, and that's fine.
Others will be open transitionally, on their way to becoming stronger
normal modules.

- Mark


[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008644.html
[2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008727.html