Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

[David M. Lloyd]

In our internal discussion of the proposal for 
#ReflectiveAccessToNonExportedTypes, we discussed the ins and outs of 
various behaviors and have come up with a few ideas or starting points 
for solutions that we think would be more workable in conjunction with 
existing middleware (ours and others').

For reasons previously explained, we do not think that weak modules are 
a good way forward; I won't go into that again here.  But the logical 
re-starting point is: If not weak modules, then what?

I will boil it down to a few basic requirements that we have 
established.  This list is probably non-exhaustive but hopefully 
complete enough to go on for now:

• A module definition must be able to establish that a dependent has (or 
all modules have) access to one or more (or all) packages for public 
reflection only.
• A module definition must be able to establish that a dependent has (or 
all modules have) access to one or more (or all) packages for public or 
private reflection only.
• A module definition must be able to establish that a dependent has (or 
all modules have) access to one or more (or all) packages for public 
reflection and compilation/linkage (i.e. it's an export by today's 
terminology).
• A module definition must be able to establish that a dependent has (or 
all modules have) access to one or more (or all) packages for public or 
private reflection and compilation/linkage (i.e. it's a "private" export 
by today's terminology).
• As today, any packages not declared in one or more of the above 
categories is inaccessible outside of the module in any way (note that 
as I showed previously we have also concluded that it should continue to 
be impossible to export a package for compilation/linkage without public 
reflection, as we have not discovered any use for such a mode).

More generally:

• The syntax for all of the above has no particular constraint (in fact 
I will try to actively avoid touching what could be a very 
bikeshedding-rich discussion), except that it should not be construable 
as being pejorative against the usage of reflective frameworks; rather, 
it should be clear what level of trust is being established without 
raising undue warning.
• Applications should not need gratuitous amounts of declarations in 
their module(s) in order to utilize frameworks.
• As previously established, it should not be possible for one 
declaration to reduce the scope of access of another declaration in a 
module definition.
• Access to a module (for reflective purposes only) must not cause 
conflicts if multiple such modules which contain identical packages are 
accessible to a single consumer; in other words, reflection-only access 
into non-dependency modules is not bound by duplicate package 
restrictions as long as each package is unique per class loader, as per 
the current (Java 8) class loader rules.

The above cover the useful access modes that we have identified.  This 
is _nearly_ adequate to cover the use cases that we are currently 
concerned about; for example, I could export all packages for public 
reflection only to a specific framework, if only I know the module name 
of the implementation.

Unfortunately, this does not work well in the case where a module may 
consume a framework whose specification is separate from the 
implementation.  An application module may need to use (say) EJB and 
JPA; there is presently no clean way to do so without either (a) relying 
on a container environment to rewrite the descriptor or (b) opening up 
the module and defeating the security mechanism (e.g. "weak").  Without 
either of these workarounds, the application developer must have a good 
deal of knowledge about what modules provide what services within a 
framework-rich environment, possibly resulting in a very verbose (and 
error-prone) descriptor; none of these options is really satisfactory.

Thus, apart from the option of redesigning (to an extent) the security 
mechanism (thereby eliminating the need to seal off access to public 
reflection, which is definitely still an attractive option for various 
reasons from our perspective, but which is also a very different 
discussion), we need some sort of mechanism which decouples the literal 
dependency system from access permission (much like uses/provides does).

For example if I could declare that my module uses "javax.ejb", and, in 
so doing, automatically grants public and private reflective access to 
the module that provides that service, this would be a good outcome.  A 
module which answers to that service name could be responsible for 
reflective access to the application module, providing that information 
privately to any other framework modules which require it.

The migration story looks much better in this light: module descriptors 
still can be quite terse and specific.  Applications which use 
reflective frameworks do not need gratuitous exports; in fact it's much 
more fluid for a user to say "I require these helper libraries; I use 
EJB; that's it" which means they don't have to worry about the details 
of whatever particular environment they run in.  This also has the 
advantage of allowing new Java 9-generation specifications to stipulate 
standard service names for each specification (e.g. "javax.ejb", 
"javax.cdi", that sort of thing).

While this doesn't cover 100% of our remaining issues with Jigsaw (of 
course; we'll all continue moving through the issues list as we have 
been to get us there), meeting these requirements would go a long way 
towards at least having a reflection story that is more practical for 
present-day frameworks to move forward with.  So the last requirement 
would be:

• A module definition must be able to establish that an "indirect" 
dependency exists on an otherwise unknown module providing a capability, 
wherein that module may require public or public+private reflection 
access to some or all packages without compile/link access.  This could 
possibly exist in conjunction with, or as an evolution of, the current 
services mechanism, however a complicating factor is that the current 
mechanism is based specifically on types, whereas a purely symbolic 
relationship might be better for this purpose (this is not a requirement 
though if it can be made to work as-is).  Note that any symbolic 
relationship system would need some in-code discovery mechanism such 
that consumers of the capability are made available to the provider 
and/or vice-versa, in order to make practical use of the relationship.

The following example syntax is meant to be unambiguous and 
illustrative; no specific attempt is made to reuse existing keywords 
(for example), or even to imply an endorsement of the current descriptor 
mechanism at all, but to clarify how this might look in practice and 
provide a practical application of the ideas herein.

Example 1: A contrived provider of the fictional framework 
"javax.fictional.orm" illustrating provides/uses-based access granting

module org.foo.orm.provider {

       // Require a module dependency, and give it private reflection 
access to everything
       requires org.apache.commons.beanutils with private reflection on *;

       // Require a module dependency with no reflection
       requires org.apache.commons.logging;

       // Provide the framework
       provides javax.fictional.orm.ORM
           using private reflection
           with org.foo.orm.provider.ORMImpl1,
                org.foo.orm.provider.ORMImpl2;
}

Example 2: A contrived consumer of #1

module com.mycompany.application {
       uses javax.fictional.orm.ORM; // automatically gives private 
reflection
}

Example 3: Grant reflection access to a couple of packages to a named 
non-dependency module

module com.mycompany.application {
       grant public reflection on
           com.mycompay.application.package1,
           com.mycompay.application.package2
       to org.foo.framework;
}

Example 4: Behave like Java 8

module com.mycompany.application {
       grant private reflection on * to *;
}

Example 5: Behave like Java 8, but restrict private access without 
requiring a security manager

module com.mycompany.application {
       grant public reflection on * to *;
}

Example 6: An example of using CDI and EJB with symbolic capabilities

module com.mycompany.application {
       uses capability javax.ejb, javax.cdi
}

Example 7: An example of providing EJB with symbolic capabilities

module org.foo.ejb.provider {
       [...]
       provides capability javax.ejb using private reflection;
}


--
- DML