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

[John Rose]

On Sep 29, 2016, at 2:29 AM, Remi Forax  wrote:
> 
> This bug only talk about the callee side, i.e. accessing to a non accessible 
> class by a framework.
> The other part, the caller side, is to have a way to emit a call that send 
> the caller lookup to a framework,
> the easy way to do that is to have javac to emit an invokedynamic instead of 
> an invokeinterface/invokevirtual
> after having verified that everything is typechecked.

FTR, I added a comment to the bug that expands on this theme.

https://bugs.openjdk.java.net/browse/JDK-8162494?focusedCommentId=14010672 


— John

P.S.  CC-ed here:

Remi Forax notes that this proposal is about gaining access to classes.
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009518.html

Once somebody (the class itself, a neighboring class, a module, a layer, the 
Unsafe API) grants you a Lookup object, you can call any class feature the 
lookup can access, by using a method handle.

The most general Lookup object, for a given class, can always be created by a 
method in the class's bytecodes that looks like this:

class C {
   private C() { } protected void m() { } int f; // etc., etc.
   public MethodHandles.Lookup grantAccess()  { return MethodHandles.lookup(); }
}

In this example, the "grantAccess" method gives the whole world (or at least 
the module) full access to all class members, up to and including privates.

The essence of the present proposal is to introduce mechanisms for creating 
Lookup objects which (a ) can be as powerful (on class C) as that returned by 
the "grantAccess" method above, and (b ) do not require any changes to the 
bytecodes of the class itself.

The difficult part of the proposal is designing the alternative Lookup factory 
in such a way that it doesn't just "give away the store" (as presumably the 
Unsafe version would).  The Lookup object should be (c ) handed out by a 
trusted delegate of C (such as its module layer), and (d ) only handed to 
callers who have been vetted in some way (such as by a SecurityManager check, 
as by setAccessible).  Finally, the Lookup object must be (e ) right-sized, so 
that it gives only access (say) to public methods, or package-private methods, 
according to the needs of the caller and the rules of the factory.

Another possible framework-like operation that Remi brings up is creating 
simulations of calls from managed framework code to other frameworks.  In some 
cases, this can also be done with the Lookup API.  If the callee is 
caller-sensitive (like Class.forName), the Lookup API handles it specially, 
embedding the Lookup's target class into the method handle it returns (for that 
callee) in such a way that when the method handle the caller-sensitive method 
observes the Lookup's target class, not the current invoker of the method 
handle.  Only the immediate caller is "edited" in this way; a full stack walk 
will see the specially-embedded caller and all of frames of the current 
invocation.

Another use case for frameworks is enumerating and examining (e.g., annotations 
of) reflected class members, instead of just invoking them.  The Lookup API is 
intended to help with this also.  The Lookup.revealDirect method can translate 
a previously accessed method handle into a Core Reflection object that 
describes the same underlying class member.  The Lookup API (as of 9) also has 
the ability to resolve class names with respect to the Lookup's target class.  
Finally (as noted above) calls to caller-sensitive Core Reflection API points 
can be made to appear originating from a target class by looking up those API 
points via a full-power Lookup on the target class, instead of calling from 
normal bytecodes.

Personally, I would like to encourage people interested in structured access 
elevation, by bona fide frameworks, to propose securable mechanisms for handing 
out Lookup objects, or similar restrictable capability objects.

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

[Peter Levart]

Hi David,

I'm not the one to answer your queries, but may I ask you some questions 
about your requirements and also give some comments...


On 09/28/2016 02:13 PM, David M. Lloyd wrote:
Hi all, I've been requested to ask if the OpenJDK development team 
have had a chance to review this email, and when we might expect a 
response.


Thanks!

On 09/21/2016 11:39 AM, David M. Lloyd wrote:

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.


Why do you think is important to have a mode that allows reflective 
access but disallows compilation/linkage? Because frameworks that use 
reflection usually have ability to dynamically adjust to changes of code 
that is exposed in that way while compilation/linkage hard-codes access 
to the code and therefore breaks when such code is changed?


I have a concern that this will not prevent breakages. If reflective 
access is allowed, you can never be sure whether someone might be using 
it and just hard-coding such access in the consuming module. So while 
not providing "easy" hard-coded access to such code, it is still 
provided, just discouraged by making it more awkward.


So I'm wondering if there might be an alternative way of "discouraging" 
hard coded access without complicating the module system with this 
aspect. A standard compile-time TYPE, PACKAGE or even MODULE annotation 
comes to mind that would trigger compilation warning if such annotated 
type or type in annotated package or type in annotated module would be 
referenced in compiled code. A warning can always be turned into an 
error for the conscious. I think this could even be implemented as an 
annotation processor, outside of javac. There just has to be a standard 
annoation to agree upon. What do you think?



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


So given above "alternative" for discouraging hard-coded access, current 
jigsaw already covers your requirements up to this point. Except maybe a 
desire to more easily "export" multiple packages with a single 
directive. I don't know why a "wildcard" export couldn't be allowed. I 
haven't heard a strong argument against it yet besides the fact that 
packages do have hierarchical naming structure, but are otherwise 
independent entities so using wildcard exports would be a precedent 
which would group a subtree of packages in a hierarchy of names and give 
them equal accessibility. But that would just accept the reality which 
is that developers usually do group packages in naming hierarchies 
according to some property. This might not be THE property which exports 
would give them (accessibility) so such feature might in fact push 
developers into grouping packages into hierarchies by the accessibility 
constraints instead of giving them freedom of unbalanced choice. So this 
might be an argument against wildcard exports...




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

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

[Remi Forax]

This bug only talk about the callee side, i.e. accessing to a non accessible 
class by a framework.
The other part, the caller side, is to have a way to emit a call that send the 
caller lookup to a framework,
the easy way to do that is to have javac to emit an invokedynamic instead of an 
invokeinterface/invokevirtual
after having verified that everything is typechecked.

As Paul said in the bug comment section, it will also allow to retrofit old API 
like the atomic reference field updaters to use VarHandles. 

Rémi

- Mail original -
> De: "Alan Bateman" <alan.bate...@oracle.com>
> À: "Andrew Dinn" <ad...@redhat.com>
> Cc: "jigsaw-dev" <jigsaw-dev@openjdk.java.net>
> Envoyé: Mercredi 28 Septembre 2016 20:09:00
> Objet: Re: Alternative mechanism for reflective access control
> (#ReflectiveAccessToNonExportedTypes /
> #AwkwardStrongEncapsulation)

> On 28/09/2016 13:22, Andrew Dinn wrote:
> 
>> :
>> I'd be happy to try to conduct such an experiment. Can you provide links
>> to the relevant JIRAs.
> The javadoc for MethodsHandes.Lookup is probably the best place to
> start, assuming you haven't used it before. This has a good section to
> explain how access checking differs to core reflection.
> 
> JDK-8162494 [1] is one issue where John has a write-up with some straw
> man designs. I suspect it will require working through a few specific
> examples to get a feel for what is the right direction.
> 
> -Alan
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8162494

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

[Andrew Dinn]

On 28/09/16 19:09, Alan Bateman wrote:
> On 28/09/2016 13:22, Andrew Dinn wrote:
>> I'd be happy to try to conduct such an experiment. Can you provide links
>> to the relevant JIRAs.
> The javadoc for MethodsHandes.Lookup is probably the best place to
> start, assuming you haven't used it before. This has a good section to
> explain how access checking differs to core reflection.
> 
> JDK-8162494 [1] is one issue where John has a write-up with some straw
> man designs. I suspect it will require working through a few specific
> examples to get a feel for what is the right direction.

Thanks, I'll look into this as soon as I can. In particular I will see
if I can use it in Byteman instead of reflection (the need to do some
class rewriting means an agent is probably the best initial candidate
for testing this).

regards,


Andrew Dinn
---

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

[David M. Lloyd]

On 09/28/2016 07:01 AM, Alan Bateman wrote:

On 28/09/2016 10:37, Gunnar Morling wrote:


:

I don't think that is what those folks asking about using the SM had
in mind.

Rather, the idea would be - IIUC - to grant code in module B (say an
ORM tool) reflective access to non-exported (and of course exported)
types in module A (say a module with entities) by default. If needed,
the code in B would then use setAccessible() for making private
members in A accessible before invoking them, allowing it to obtain
the entity state. This is where the SM is part of the picture: if in a
given environment the user wants to restrict who may call
setAccessible(), they could use the SM for it, with a fine grained
policy, e.g. allowing the call only to the ORM module.

I.e. ReflectiveAccessToNonExportedTypes would be granted by default,
only if an SM is enabled at runtime, actions to suppress accessibility
checks would be subject to the current security policy.

This is not to say that I'm behind this idea, I just felt it hasn't
been discussed in the way it may have been meant.

I can see though how JDK devs and library authors want to prevent
access to private code in their modules at all, hence relying on the
SM to be enabled at runtime is not an option to address that requirement.


The original question mentioned "reflective access" and we've said, has
always been specified to do the same access checks as the Java Language
and VM.

On setAccessible, then it wouldn't be hard to have setAccessible
implement fine grain permission checks but not clear how useful this is
given that the SM is opt-in and not widely used. Having setAccessible
ignore module boundaries (assume no SM) goes against the goal of strong
encapsulation and of course makes #AwkwardStrongEncapsulation a lot worse.

In general then I think that we need to find ways to reduce the use of
setAccessible over time. We really need a long term plan to degrade,
deprecate and eventually remove it. This would of course mean working on
some challenging problems and use-cases.

So what would the alternative to setAccessible be? It would be nice if
the framework libraries (you mention ORM tools and maybe the Hibernate
ORM devs could be the guinea pig) would start to make use of the "new
reflection API" that is java.lang.invoke. So rather than bypassing
access checks with legacy core reflection then they would instead use
MH.Lookup objects as capabilities. Think code in a consumer module
creating a Lookup object with the appropriate lookup class + mode that
it cooperatively hands to the framework. This puts the access check in
the consumer module so that the frameworks don't need to break in. This
direction isn't without challenges of course as there may be
initialization issues to deal with. It might, for example, involve
injecting helper code into a submissive consumer module when there isn't
explicit initialization. John Rose has good write-ups in JIRA with ideas
in this area.


Using Lookups are very likely to be an essential piece to solving the 
security conundrum.  It is not without its problems though at present.


Bytecode injection in particular only works in a container setting, for 
example, and only for wholly managed modules.  Relying on cooperative 
code is also a comparatively onerous burden to place on regular 
application developers, and of course few if any existing frameworks and 
standards are set up in this way so it doesn't help the migration story any.


More work definitely needs to be done in this area before we can really 
say that it's a viable alternative to setAccessible().

--
- DML

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

[Andrew Dinn]

On 28/09/16 13:01, Alan Bateman wrote:
> In general then I think that we need to find ways to reduce the use of
> setAccessible over time. We really need a long term plan to degrade,
> deprecate and eventually remove it. This would of course mean working on
> some challenging problems and use-cases.
> 
> So what would the alternative to setAccessible be? It would be nice if
> the framework libraries (you mention ORM tools and maybe the Hibernate
> ORM devs could be the guinea pig) would start to make use of the "new
> reflection API" that is java.lang.invoke. So rather than bypassing
> access checks with legacy core reflection then they would instead use
> MH.Lookup objects as capabilities. Think code in a consumer module
> creating a Lookup object with the appropriate lookup class + mode that
> it cooperatively hands to the framework. This puts the access check in
> the consumer module so that the frameworks don't need to break in. This
> direction isn't without challenges of course as there may be
> initialization issues to deal with. It might, for example, involve
> injecting helper code into a submissive consumer module when there isn't
> explicit initialization. John Rose has good write-ups in JIRA with ideas
> in this area.

I'd be happy to try to conduct such an experiment. Can you provide links
to the relevant JIRAs.

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

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

[David M. Lloyd]

Hi all, I've been requested to ask if the OpenJDK development team have 
had a chance to review this email, and when we might expect a response.


Thanks!

On 09/21/2016 11:39 AM, David M. Lloyd wrote:

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.  

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

[David M. Lloyd]

On 09/28/2016 04:37 AM, Gunnar Morling wrote:

 If I'm compiling a class A that has a reference to a member in type B
then do you really want the compiler calling into a security manager to
ask if this access is allowed?


I don't think that is what those folks asking about using the SM had in
mind.

Rather, the idea would be - IIUC - to grant code in module B (say an ORM
tool) reflective access to non-exported (and of course exported) types in
module A (say a module with entities) by default. If needed, the code in B
would then use setAccessible() for making private members in A accessible
before invoking them, allowing it to obtain the entity state. This is where
the SM is part of the picture: if in a given environment the user wants to
restrict who may call setAccessible(), they could use the SM for it, with a
fine grained policy, e.g. allowing the call only to the ORM module.

I.e. ReflectiveAccessToNonExportedTypes would be granted by default, only
if an SM is enabled at runtime, actions to suppress accessibility checks
would be subject to the current security policy.

This is not to say that I'm behind this idea, I just felt it hasn't been
discussed in the way it may have been meant.

I can see though how JDK devs and library authors want to prevent access to
private code in their modules at all, hence relying on the SM to be enabled
at runtime is not an option to address that requirement.


Note that as a security mechanism for untrusted code, this mechanism is 
not going to be adequate no matter what.  The person who has control of 
the deployment environment can always change the module to accommodate 
their case.  I'm sure it will be a very short time after finalization 
before we see module editing tools in the wild to accomplish exactly 
this.  This is an inevitable consequence of bundling the module 
definition within the module itself.


Only the JDK has any real ability to enforce this kind of security, 
though of course it's always possible to defeat that as well (it's just 
potentially a lot more work).


The chief tangible protection which is expected to be afforded by this 
mechanism is against malicious exploitation of trusted code.

--
- DML

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

[David M. Lloyd]

On 09/28/2016 05:31 AM, Gunnar Morling wrote:

David,


there is too much existing work out there, and the requirements go far

beyond

what can be satisfied by these simple questions.


What are examples for such requirements? I.e. what from the list of your
requirements cannot be mapped to the mechanism suggested by Stephen? I
find his proposal quite appealing and am wondering whether it couldn't
be tweaked to cater for the remaining requirements.


I would rather in this case ask: how does his proposal solve all of our 
requirements?  The burden is always on the implementer to solve 
requirements, not the other way around.



Btw. I second the concern that the exposure of internal parts for
reflective access should not be implicitly enabled by merely depending
on a module requesting such access. It seems too easy for users to
accidentally give access to internal code without being aware of it.


Possibly.  But that's a usability concern and does not change the 
requirement.


For example it's not hard to imagine that someone importing such a 
module has to acknowledge the requested access explicitly (without 
defining the specifics of it) in order for the module to successfully 
link.  Of course that's just one idea to illustrate that the requirement 
can be addressed; it's not a proposal.





2016-09-27 16:30 GMT+02:00 David M. Lloyd >:

Hi Stephen,

I just want to point out that this isn't a proposal per se.  I don't
advocate any particular syntax, nor recommendation for patterns that
users should use.  This is merely a set of requirements that we (Red
Hat) have identified as necessary in order to enable the widest
range of existing middleware systems to continue to function with a
minimum of disruption or security compromises.  Any proposal that we
accept will necessarily meet these requirements, though these
requirements may or may not be sufficient for acceptance (only
testing will tell us the full story).

The reason I didn't boil it down to the same set of questions that
you have asked is that those questions are simply not sufficient to
meet the requirements of a modern middleware application.  To quote
the JSR description: "This JSR will define an approachable yet
scalable module system [...] so that developers can use it to
construct and maintain libraries and large applications for both the
Java SE and Java EE Platforms. [...]"

I think it's very possible for the platform module system to be
specified and implemented in such a way as to enable the continued
maintenance of existing libraries and large applications, however in
order to do so, it is our estimation that these requirements must be
met.

In response to the way you've narrowed down the scope of
requirements: I agree that such simplifications work well when
establishing boundaries for a new project and encouraging good usage
patterns.  But I don't think we can really do that here; there is
too much existing work out there, and the requirements go far beyond
what can be satisfied by these simple questions.


On 09/26/2016 05:11 AM, Stephen Colebourne wrote:

Having read this proposal a number of times, and considering how the
talks explained things at JavaOne, I have come to the conclusion
that
this proposal is too complex. FWIW, I like the idea that a module
should be able to declare that it needs reflective access from its
users, however given that the proposal is what results from the
idea,
it doesn't seem as appealing as it should.

The reason why I put forward the exports/exposes approach [1] is
that
it keeps the questions that must be asked when creating a module
simple:
- what do I depend on publicly (requires)
- what do I publish publicly (exports)
- what do I publish privately (exposes)

From a security point of view it also seems that it should be the
responsibility of a module to allow the publishing of its private
details, and simply depending on another module seems very minimal
(and easy to miss) as a mechanism to allow that extra permission.

Stephen

[1]

http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009370.html




On 21 September 2016 at 17:39, David M. Lloyd
> wrote:

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 

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

[Gunnar Morling]

David,

> there is too much existing work out there, and the requirements go far
beyond
> what can be satisfied by these simple questions.

What are examples for such requirements? I.e. what from the list of your
requirements cannot be mapped to the mechanism suggested by Stephen? I find
his proposal quite appealing and am wondering whether it couldn't be
tweaked to cater for the remaining requirements.

Btw. I second the concern that the exposure of internal parts for
reflective access should not be implicitly enabled by merely depending on a
module requesting such access. It seems too easy for users to accidentally
give access to internal code without being aware of it.


2016-09-27 16:30 GMT+02:00 David M. Lloyd :

> Hi Stephen,
>
> I just want to point out that this isn't a proposal per se.  I don't
> advocate any particular syntax, nor recommendation for patterns that users
> should use.  This is merely a set of requirements that we (Red Hat) have
> identified as necessary in order to enable the widest range of existing
> middleware systems to continue to function with a minimum of disruption or
> security compromises.  Any proposal that we accept will necessarily meet
> these requirements, though these requirements may or may not be sufficient
> for acceptance (only testing will tell us the full story).
>
> The reason I didn't boil it down to the same set of questions that you
> have asked is that those questions are simply not sufficient to meet the
> requirements of a modern middleware application.  To quote the JSR
> description: "This JSR will define an approachable yet scalable module
> system [...] so that developers can use it to construct and maintain
> libraries and large applications for both the Java SE and Java EE
> Platforms. [...]"
>
> I think it's very possible for the platform module system to be specified
> and implemented in such a way as to enable the continued maintenance of
> existing libraries and large applications, however in order to do so, it is
> our estimation that these requirements must be met.
>
> In response to the way you've narrowed down the scope of requirements: I
> agree that such simplifications work well when establishing boundaries for
> a new project and encouraging good usage patterns.  But I don't think we
> can really do that here; there is too much existing work out there, and the
> requirements go far beyond what can be satisfied by these simple questions.
>
>
> On 09/26/2016 05:11 AM, Stephen Colebourne wrote:
>
>> Having read this proposal a number of times, and considering how the
>> talks explained things at JavaOne, I have come to the conclusion that
>> this proposal is too complex. FWIW, I like the idea that a module
>> should be able to declare that it needs reflective access from its
>> users, however given that the proposal is what results from the idea,
>> it doesn't seem as appealing as it should.
>>
>> The reason why I put forward the exports/exposes approach [1] is that
>> it keeps the questions that must be asked when creating a module
>> simple:
>> - what do I depend on publicly (requires)
>> - what do I publish publicly (exports)
>> - what do I publish privately (exposes)
>>
>> From a security point of view it also seems that it should be the
>> responsibility of a module to allow the publishing of its private
>> details, and simply depending on another module seems very minimal
>> (and easy to miss) as a mechanism to allow that extra permission.
>>
>> Stephen
>>
>> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-Septe
>> mber/009370.html
>>
>>
>> On 21 September 2016 at 17:39, David M. Lloyd 
>> wrote:
>>
>>> 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 

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

[Gunnar Morling]

>  If I'm compiling a class A that has a reference to a member in type B
> then do you really want the compiler calling into a security manager to
> ask if this access is allowed?

I don't think that is what those folks asking about using the SM had in
mind.

Rather, the idea would be - IIUC - to grant code in module B (say an ORM
tool) reflective access to non-exported (and of course exported) types in
module A (say a module with entities) by default. If needed, the code in B
would then use setAccessible() for making private members in A accessible
before invoking them, allowing it to obtain the entity state. This is where
the SM is part of the picture: if in a given environment the user wants to
restrict who may call setAccessible(), they could use the SM for it, with a
fine grained policy, e.g. allowing the call only to the ORM module.

I.e. ReflectiveAccessToNonExportedTypes would be granted by default, only
if an SM is enabled at runtime, actions to suppress accessibility checks
would be subject to the current security policy.

This is not to say that I'm behind this idea, I just felt it hasn't been
discussed in the way it may have been meant.

I can see though how JDK devs and library authors want to prevent access to
private code in their modules at all, hence relying on the SM to be enabled
at runtime is not an option to address that requirement.

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

[David M. Lloyd]

Hi Stephen,

I just want to point out that this isn't a proposal per se.  I don't 
advocate any particular syntax, nor recommendation for patterns that 
users should use.  This is merely a set of requirements that we (Red 
Hat) have identified as necessary in order to enable the widest range of 
existing middleware systems to continue to function with a minimum of 
disruption or security compromises.  Any proposal that we accept will 
necessarily meet these requirements, though these requirements may or 
may not be sufficient for acceptance (only testing will tell us the full 
story).


The reason I didn't boil it down to the same set of questions that you 
have asked is that those questions are simply not sufficient to meet the 
requirements of a modern middleware application.  To quote the JSR 
description: "This JSR will define an approachable yet scalable module 
system [...] so that developers can use it to construct and maintain 
libraries and large applications for both the Java SE and Java EE 
Platforms. [...]"


I think it's very possible for the platform module system to be 
specified and implemented in such a way as to enable the continued 
maintenance of existing libraries and large applications, however in 
order to do so, it is our estimation that these requirements must be met.


In response to the way you've narrowed down the scope of requirements: I 
agree that such simplifications work well when establishing boundaries 
for a new project and encouraging good usage patterns.  But I don't 
think we can really do that here; there is too much existing work out 
there, and the requirements go far beyond what can be satisfied by these 
simple questions.


On 09/26/2016 05:11 AM, Stephen Colebourne wrote:

Having read this proposal a number of times, and considering how the
talks explained things at JavaOne, I have come to the conclusion that
this proposal is too complex. FWIW, I like the idea that a module
should be able to declare that it needs reflective access from its
users, however given that the proposal is what results from the idea,
it doesn't seem as appealing as it should.

The reason why I put forward the exports/exposes approach [1] is that
it keeps the questions that must be asked when creating a module
simple:
- what do I depend on publicly (requires)
- what do I publish publicly (exports)
- what do I publish privately (exposes)

From a security point of view it also seems that it should be the
responsibility of a module to allow the publishing of its private
details, and simply depending on another module seems very minimal
(and easy to miss) as a mechanism to allow that extra permission.

Stephen

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009370.html


On 21 September 2016 at 17:39, David M. Lloyd  wrote:

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 

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

[Andrew Dinn]

On 27/09/16 12:34, Alan Bateman wrote:
> On the specific topic of using the security manager to do JLS and JVMS
> specified access checks then it doesn't make any sense to me. If I'm
> compiling a class A that has a reference to a member in type B then do
> you really want the compiler calling into a security manager to ask if
> this access is allowed? Security managers don't know anything about the
> access control at this level. The permission checks that a security
> manager does involve stack walks and computing the intersection of
> permissions to see if the effective permissions are granted or not. This
> is right when checking access to security sensitive resources (network
> end points or files for example) but not at the level of checking if A
> has access to a member of B. At run-time then would you really want the
> the VM calling out to a security manager when doing JVMS-specified
> access checks? If there is no security manager (the common case) then
> does it mean that code in class A can access a private field in class B.
> Going further then executing the security manager's checkPermission will
> likely involve access checks in the VM so how would you handle those?
> Hopefully you'll start to see that the access checks that we dealing
> with here are at a completely different level to the permission checks
> that a security manager implements.

Thank you for this very helpful explanation (n.b. I'm taking all
embedded questions as rhetorical). I hope it satisfies the original poster.

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

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

[Alan Bateman]

On 26/09/2016 17:37, Andrew Dinn wrote:


:
That's very good to hear, because your previous phrasing certainly
brought that commitment into question. As I am afraid does your
continued unwillingness to provide motivation for why the current Jigsaw
implementation operates in the way it does.

n.b. I'm not saying this because I personally want to see Jigsaw
drastically changed (although I know others, such as my colleague David
Lloyd, have good reasons for requesting significant changes). No, it's
rather because I think it is important that the rationale for one choice
over another conflicting choice is articulated openly so that the
consequences of making or rejecting any such choice can be understood
and their pros and cons correctly weighed in the balance by all OpenJDK
project members and users who are willing to expend the effort needed to
understand and review those consequences. Isn't that how this project is
supposed to work?

To your last paragraph, this project has an associated JSR and so design 
issues and proposals are discussed on jpms-spec-experts. There are 
associated -observers and -comments lists for those that want to follow 
and comment. Implementation issues are discussed here. It's impossible 
to distinguish the discussions sometimes, especially on this list as 
there are lots of passionate people with wildly different perspectives 
and expectations.


As regards design proposals then there are an infinite number of 
choices, esp. when you get into the details. In all honestly, there just 
isn't time in the day to write up all the details of every possible path.


On the specific topic of using the security manager to do JLS and JVMS 
specified access checks then it doesn't make any sense to me. If I'm 
compiling a class A that has a reference to a member in type B then do 
you really want the compiler calling into a security manager to ask if 
this access is allowed? Security managers don't know anything about the 
access control at this level. The permission checks that a security 
manager does involve stack walks and computing the intersection of 
permissions to see if the effective permissions are granted or not. This 
is right when checking access to security sensitive resources (network 
end points or files for example) but not at the level of checking if A 
has access to a member of B. At run-time then would you really want the 
the VM calling out to a security manager when doing JVMS-specified 
access checks? If there is no security manager (the common case) then 
does it mean that code in class A can access a private field in class B. 
Going further then executing the security manager's checkPermission will 
likely involve access checks in the VM so how would you handle those? 
Hopefully you'll start to see that the access checks that we dealing 
with here are at a completely different level to the permission checks 
that a security manager implements.


-Alan.

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

[dalibor topic]

On 27.09.2016 13:01, dalibor topic wrote:



On 27.09.2016 12:03, Andrew Dinn wrote:

Yes we could use braces instead of a
belt, but why do we /need/ braces when we can already wear a belt?


I don't think that it's an either one or another proposition,

Although the developing fashion sense in some countries dictated going
with either one or the other choice, with belts reigning supreme among
many market constituents, among heavy duty work clothing, using
suspenders (braces) along with duty belts tends to provide better
ergonomics due to better distribution of weight across shoulders and
back away from lower back alone, resulting in lower back pain incidence
among wearers.

Please see Slide 24 of
http://www.gvsafety.com/documents/SAFETY%20HANDOUTS/Construction%20Safety/Construction%20Topics/Ergonomic%20Practices%20for%20Framers-Power%20Point.pdf
for an example of such work safety recommendations and
http://scholarworks.gvsu.edu/cgi/viewcontent.cgi?article=1641=theses
for an example of research on the benefits of using suspenders to reduce
lower back pain in police officers, that often need to carry heavy duty
belts.


And for historical fashion discussion in this area, please see (or 
rather listen to) 
http://freakonomics.com/podcast/how-did-the-belt-win-a-new-freakonomics-radio-episode/ 
.


cheers,
dalibor topic

--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

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

[dalibor topic]

On 27.09.2016 12:03, Andrew Dinn wrote:

Yes we could use braces instead of a
belt, but why do we /need/ braces when we can already wear a belt?


I don't think that it's an either one or another proposition,

Although the developing fashion sense in some countries dictated going 
with either one or the other choice, with belts reigning supreme among 
many market constituents, among heavy duty work clothing, using 
suspenders (braces) along with duty belts tends to provide better 
ergonomics due to better distribution of weight across shoulders and 
back away from lower back alone, resulting in lower back pain incidence 
among wearers.


Please see Slide 24 of 
http://www.gvsafety.com/documents/SAFETY%20HANDOUTS/Construction%20Safety/Construction%20Topics/Ergonomic%20Practices%20for%20Framers-Power%20Point.pdf 
for an example of such work safety recommendations and 
http://scholarworks.gvsu.edu/cgi/viewcontent.cgi?article=1641=theses 
for an example of research on the benefits of using suspenders to reduce 
lower back pain in police officers, that often need to carry heavy duty 
belts.


cheers,
dalibor topic
--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

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

[Remi Forax]

- Mail original -
> De: "Andrew Dinn" <ad...@redhat.com>
> À: "Alan Bateman" <alan.bate...@oracle.com>
> Cc: jigsaw-dev@openjdk.java.net
> Envoyé: Lundi 26 Septembre 2016 13:36:46
> Objet: Re: Alternative mechanism for reflective access control    
> (#ReflectiveAccessToNonExportedTypes /
> #AwkwardStrongEncapsulation)

[...]

> I addressed that in the text you snipped. The one point of relevance is
> that which the original poster asked about:
> 
>  -- Why do we need Jigsaw to constrain access control when we can do so
> using a security manager?
> 
> Do you (or anyone else involved in defining and implementing Jigsaw)
> have an answer to that question?

If a code becomes modular, what jigsaw changes is that by default you can not 
see non exported packages or use setAccessible.
In both cases, those features are enforced by security checks done by the VM.
A SecurityManager is something used to implement a peculiar security policy on 
top of the Java VM security, you can not disable any VM checks with a security 
manager.
So from my planet, it is weird to think that the security manager can be 
involved :)

regards,
Rémi


> 
> Andrew Dinn
> ---
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

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

[Andrew Dinn]

On 27/09/16 10:27, dalibor topic wrote:
> On 26.09.2016 18:37, Andrew Dinn wrote:

[snip]

>> I think those involved in this discussion already know all that you have
>> stated here regarding /what/ this project is doing. The present question
>> is /why/ is something that it is doing needed.
> 
> Paraphrasing, your question seems to be
> 
> "If A is true, why does B need to be true?"
> 
> whereas Alan's answer seems to be
> 
> "A is not universally true."

I'm not sure a truth-theoretic analysis quite captures the argument
correctly but ... it's nice to actually see someone begin to address the
original poster's question.

> So it appears that he answered this specific question by providing two
> counter examples:
> 
>   1. "no security manager at runtime", and
>   2. "no equivalent at compile time"
> 
> when A (i.e. being able to constrain access control using a security
> manager) can not be true.

You seem to be saying that Alan's argument (one that I am sorry I failed
to spot) is we can may already have a belt (security manager) but we can
also do with braces (jigsaw access restrictions) because you might
choose not to wear a belt and the braces would serve instead to cover
your modesty. That is indeed an argument and might be all that is needed
if choice of belt and/or braces were all one. Unfortunately, the
question of their efficacy and their potential for collateral hindrance
(as opposed to vertical benefit) that was at the heart of the original
question is still left unaddressed. Yes we could use braces instead of a
belt, but why do we /need/ braces when we can already wear a belt?

Stressing the optionality of wearing a belt does not really answer the
question as to whether the braces proffered as alternative improve on
our current options. Your argument could equally be used to deprecate
Jigsaw's (symmetrically optional) access restrictions as 'legacy' and,
instead, promote use of security managers. It certainly doesn't address
the clearly expressed feeling that Jigsaw might make important things
worse and, clearly, there is a strong feeling amongst some posters here
that it does make some things very much worse. Equally, it doesn't
present what makes Jigsaw better. As an example of the former, let's
note that although use of Jigsaw is also optional -- in that no one has
to package code as a module -- compared with the security manager model
the choice is no longer quite so flexible since it is not left in the
hands of the end user (i.e. a library jar published as a module leaves
no room for a consumer of that jar to redefine the accessibility without
rebuilding from a tweaked source). I am not saying that this difference
is a good or bad thing (after the changes made to support agent access I
no longer have a dog in this fight). Also, I'm not going to provide a
positive example to promote Jigsaw (I can think of several) because I
think it is really up to members of the Jigsaw project to do that and no
doubt they can do it more effectively than I can. The real point here is
that I don't think Alan's answer (as you present it above) is
satisfactory when such aspects of the original question have not been
addressed.

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

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

[dalibor topic]

On 26.09.2016 18:37, Andrew Dinn wrote:

On 26/09/16 14:19, Alan Bateman wrote:

On 26/09/2016 12:36, Andrew Dinn wrote:


:
I addressed that in the text you snipped. The one point of relevance is
that which the original poster asked about:

   -- Why do we need Jigsaw to constrain access control when we can do so
using a security manager?


[snip]


The access checks happen irrespective of whether there is a security
manager or not (and of course there is no equivalent at compile time).


[snip]


I think those involved in this discussion already know all that you have
stated here regarding /what/ this project is doing. The present question
is /why/ is something that it is doing needed.


Paraphrasing, your question seems to be

"If A is true, why does B need to be true?"

whereas Alan's answer seems to be

"A is not universally true."

So it appears that he answered this specific question by providing two 
counter examples:


  1. "no security manager at runtime", and
  2. "no equivalent at compile time"

when A (i.e. being able to constrain access control using a security 
manager) can not be true.


cheers,
dalibor topic

--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

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

[Eric Johnson]

On 9/25/16 8:50 PM, GREGG WONDERLY wrote:

I still, like others seem to, find it amazingly odd, that the security manager, 
existing basis for access control is not still what would count.
I'm with you there. I'm fascinated that this thread has triggered 
references to the "legacy" security manager. Somehow, the security 
manager is defacto not worth extending / expanding, but this whole 
module boundary enforcement scheme is.

   I understand that the JDK itself is not deployed with a security manager 
impl in most cases, and thus there would be no access context for the security 
manager to be used against.
A different way of framing this whole discussion, though, is to say that 
with Jigsaw, Java always runs with some kind of "security manager". 
Oracle may not want to call it that (whatever, it is just a name), but 
that's effectively what it is. What is annoying / odd / frustrating is 
that there's no variability in implementation. The discussion on this 
list has made it crystal clear that the JSR authors did not fully 
anticipate the range of security people would need to impose. Using an 
analogy, even SELinux has configurations where boundary violations are 
merely logged, not blocked.



   What’s odd, is that you are still trying to block access to reflective 
access to the “open JDK”.  If it’s really open and it’s really something that 
the community contributes to, why do we need to block access, hide details and 
otherwise obfuscate access details?  Modularization should just be about 
separating pieces not needed should it not?
Well, yes and no. I'm all for modularizing the JDK. Yet, for effective 
modularization, you have to hide things at compile time. The treatment 
of com.sun.* APIs over the years is clear indication that merely 
flagging these issues as warnings will not keep people from poking 
around the innards. The details need to be blocked, or people will keep 
using (exploiting?) them.

   Why has this degenerated into such a huge bit of access restriction too?
Runtime enforcement is another problem. I respect Oracle's (implicit) 
position that they need to block access to the "non-published" aspects 
of the JDK. Why? Because every API they can hide reduces the attack 
surface for every application that runs in the ecosystem. By in large, 
that's entirely a good thing. My company's products have in the past 
been exposed to this very problem - reflective access to the innards of 
the JDK enabled possible attacks - /merely by the presence of the wrong 
version of a JAR file in the classpath/. If the JDK innards were hidden 
at the time, the attack avenue would have been blocked.


Taking enforcement further, though, becomes problematic very quickly. I 
suspect the best way to inform that discussion would be with well 
explored threat models. That way, we'd know what the new module 
boundaries are supposed to be protecting us from. With the current 
Jigsaw approach, it seems logical that if it is good for the JDK to 
reduce its attack surface, that it is likely a good thing for everything 
that runs on top of the JDK. However, that's making all sorts of 
assumptions about threats. So what we seem to be left with on this 
mailing list is continued exploration of use-cases that run afoul of the 
"reduce attack surfaces for everything" approach. Whereas I think we'd 
all benefit from looking at the different threat models.

Could people who think that modularity should solve these problems and the 
security manager not be part of the solution please provide some details about 
how security is the modularization mechanisms responsibility and not the 
security managers?  For deployment, I’ve always used the security manager to 
limit/control access when I take some 3rd party code/jar and deploy it into a 
production environment.  That helps me restrict its access to resources in a 
manageable and maintainable way.

What I see happening, is that this single issue of “access” to pieces of 
software, from other pieces of software is degenerating into huge amounts of 
complexity and specification and release control, which isn’t really what makes 
“open software” work together.
I think the "open software" aspect is likely unimportant. Huge amounts 
of complexity and specification are an anti-pattern in any environment. 
Particularly in the realm of any kind of security enforcement, the 
simpler the better. The more complex the rules, the more likely it is 
that the implementation makes a mistake.


Eric.

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

[Andrew Dinn]

On 26/09/16 14:19, Alan Bateman wrote:
> On 26/09/2016 12:36, Andrew Dinn wrote:
> 
>> :
>> I addressed that in the text you snipped. The one point of relevance is
>> that which the original poster asked about:
>>
>>-- Why do we need Jigsaw to constrain access control when we can do so
>> using a security manager?
>>
>> Do you (or anyone else involved in defining and implementing Jigsaw)
>> have an answer to that question?
> This project updates the Java Language to support modules. The access
> checks that we are talking about happen at compile time and run time.
> The access checks happen irrespective of whether there is a security
> manager or not (and of course there is no equivalent at compile time).
> I'm not sure that there is much more to say on this, the security
> manager is not really relevant to what we are doing here.

I think those involved in this discussion already know all that you have
stated here regarding /what/ this project is doing. The present question
is /why/ is something that it is doing needed. It seems that there has
been no real explanation of this on the JSR EG list. You seem to be
unwilling to offer any real explanation here. I cannot see a failure to
provide such a rationale as less than failing to live up to the open
source consultation process that this project is meant to be following.
Perhaps someone on the Governing Board could step in here in order to
consider this lacuna?

>> Also, you have used the phrase twice now so I have to ask. Where does
>> the notion that the "legacy security manager mechanism" is actually a
>> legacy mechanism come from? Is it to be retired? Or are you just saying
>> that you think it ought to be legacy because you think Jigsaw makes it
>> redundant?
> Sandboxing with a security manager is legacy and has been highly
> problematic for a long time. It has not been retired although I think a
> good discussion for elsewhere on whether it should be deprecated. The
> only connection to modules is that strong encapsulation makes the
> platform more secure. Modules is not a replacement for the security
> manager.

It id difficult to see the security manager mechanism as being as
unquestionably 'legacy' and 'highly problematic' as you assert when the
person who asked the question stated:

  "For deployment, I’ve always used the security manager to
limit/control access when I take some 3rd party code/jar and deploy it
into a production environment.  That helps me restrict its access to
resources in a manageable and maintainable way."

Your response here comes across as a refusal to entertain the legitimacy
of the original question yet it seems to me to be a perfectly legitimate
question. You have not actually provided any evidence as to why use of a
security manager to manage access is inadequate or, at least, inferior
to the control that Jigsaw provides. If you or the project devs don't
know that then who is to explain why the latter is being added to the
JDK runtime?

Also, I am still concerned at your use of the word 'legacy'. Not only
has this mechanism not been 'retired', you acknowledge that there are no
such plans afoot. In what sense can a feature be 'legacy' when it is
part of the implementation, has not been marked as deprecated, has no
accepted alternative (not until Jigsaw is agreed) and is happily
employed by (some) current users. To me that's a very strange form of
'legacy'.

  . . .

> There is is nothing being waved away or taking lightly. This project has
> a stated goal to provide support for strong encapsulation. This has a
> lot of implications that we've trying to work through. We of course know
> that strong encapsulation isn't for all modules, hence the proposal on
> the JSR list to provide a simple means to get the benefits of reliable
> configuration without opting in to strong encapsulation.

That's very good to hear, because your previous phrasing certainly
brought that commitment into question. As I am afraid does your
continued unwillingness to provide motivation for why the current Jigsaw
implementation operates in the way it does.

n.b. I'm not saying this because I personally want to see Jigsaw
drastically changed (although I know others, such as my colleague David
Lloyd, have good reasons for requesting significant changes). No, it's
rather because I think it is important that the rationale for one choice
over another conflicting choice is articulated openly so that the
consequences of making or rejecting any such choice can be understood
and their pros and cons correctly weighed in the balance by all OpenJDK
project members and users who are willing to expend the effort needed to
understand and review those consequences. Isn't that how this project is
supposed to work?

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

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

[Remi Forax]

+1

Rémi

- Mail original -
> De: "Stephen Colebourne" <scolebou...@joda.org>
> À: "jigsaw-dev" <jigsaw-dev@openjdk.java.net>
> Envoyé: Lundi 26 Septembre 2016 12:11:58
> Objet: Re: Alternative mechanism for reflective access control    
> (#ReflectiveAccessToNonExportedTypes /
> #AwkwardStrongEncapsulation)

> Having read this proposal a number of times, and considering how the
> talks explained things at JavaOne, I have come to the conclusion that
> this proposal is too complex. FWIW, I like the idea that a module
> should be able to declare that it needs reflective access from its
> users, however given that the proposal is what results from the idea,
> it doesn't seem as appealing as it should.
> 
> The reason why I put forward the exports/exposes approach [1] is that
> it keeps the questions that must be asked when creating a module
> simple:
> - what do I depend on publicly (requires)
> - what do I publish publicly (exports)
> - what do I publish privately (exposes)
> 
> From a security point of view it also seems that it should be the
> responsibility of a module to allow the publishing of its private
> details, and simply depending on another module seems very minimal
> (and easy to miss) as a mechanism to allow that extra permission.
> 
> Stephen
> 
> [1] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009370.html
> 
> 
> On 21 September 2016 at 17:39, David M. Lloyd <david.ll...@redhat.com> wrote:
>> 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 

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

[Alan Bateman]

On 26/09/2016 12:36, Andrew Dinn wrote:


:
I addressed that in the text you snipped. The one point of relevance is
that which the original poster asked about:

   -- Why do we need Jigsaw to constrain access control when we can do so
using a security manager?

Do you (or anyone else involved in defining and implementing Jigsaw)
have an answer to that question?
This project updates the Java Language to support modules. The access 
checks that we are talking about happen at compile time and run time. 
The access checks happen irrespective of whether there is a security 
manager or not (and of course there is no equivalent at compile time). 
I'm not sure that there is much more to say on this, the security 
manager is not really relevant to what we are doing here.





Also, you have used the phrase twice now so I have to ask. Where does
the notion that the "legacy security manager mechanism" is actually a
legacy mechanism come from? Is it to be retired? Or are you just saying
that you think it ought to be legacy because you think Jigsaw makes it
redundant?
Sandboxing with a security manager is legacy and has been highly 
problematic for a long time. It has not been retired although I think a 
good discussion for elsewhere on whether it should be deprecated. The 
only connection to modules is that strong encapsulation makes the 
platform more secure. Modules is not a replacement for the security manager.




:
I find your account of the specification to be very misleading then. Of
course code employing reflection has to protect against IAE because the
methods it uses include it as a checked exception. But the core
reflection API is also specified to provide setAccessible and it has
always been possible to rely on that method to ensure that IAE does not
actually get thrown in a large and well-defined set of cases.
I was trying to point out that core reflection has always been specified 
to do the same access checks as the Java Language..


The setAccessible method is for suppressing Java Language access checks. 
As I've said elsewhere, then changing this to align with the proposal 
for #AwkwardStrongEncapsulation is a very disruptive change and there 
many issues to work through.



:

To describe a severe reduction of that set of cases with the words
"there is nothing really here" seems to be even more misleading than
your partial account of the specified API. Given that this has been the
topic of intense discussion and debate here for the last few months I
find it hard to understand how you expect to wave it away with such
light words. Perhaps it would be better if you provided those who are
concerned by this change with a better account of why it really is
needed -- or maybe even considered working towards some more limited
change that attempt to meet both their needs and yours.

There is is nothing being waved away or taking lightly. This project has 
a stated goal to provide support for strong encapsulation. This has a 
lot of implications that we've trying to work through. We of course know 
that strong encapsulation isn't for all modules, hence the proposal on 
the JSR list to provide a simple means to get the benefits of reliable 
configuration without opting in to strong encapsulation.


-Alan

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

[Andrew Dinn]

On 26/09/16 12:11, Alan Bateman wrote:
> On 26/09/2016 10:28, Andrew Dinn wrote:
> 
>> :
>> I'm sorry, Alan ,but I think that is disingenuous. When we see "access
>> control" on this list all of us really ought to bear in mind what have
>> been the de facto access control mechanisms for many JDK releases and
>> many more years. There are two such levels of control and one of them is
>> the security manager. That's a historic fact. Your statement above reads
>> very much like an attempt to hijack the discourse by hijacking
>> terminology so it addresses the topic you want to talk about (there is
>> no imputation of such a motive here -- I'm just reporting how it looks).
> I was simply pointing out that when we are discussing access control
> here then we're talking about the access control that is enforced by the
> Java Language and VM.  No new terminology.
> 
> It is unfortunate that the legacy security manager mechanism also uses
> the term "access control" but it's completely different mechanism that
> is not relevant to anything we are doing here.

I addressed that in the text you snipped. The one point of relevance is
that which the original poster asked about:

  -- Why do we need Jigsaw to constrain access control when we can do so
using a security manager?

Do you (or anyone else involved in defining and implementing Jigsaw)
have an answer to that question?

Also, you have used the phrase twice now so I have to ask. Where does
the notion that the "legacy security manager mechanism" is actually a
legacy mechanism come from? Is it to be retired? Or are you just saying
that you think it ought to be legacy because you think Jigsaw makes it
redundant? If the former then can you point out where the decision was
consulted on and agreed by the OpenJDK community? If the latter then I
would regard that as yet more of an imperative for you provide the
original poster with an answer (I'd also advise that you stop using the
term so definitively).

>> Has this really been the specification? If so then many years of
>> differing practice as regards the implementation have made that
>> 'putative' specification worth less than the paper it is (probably no
>> longer :-) printed on.
> The core reflection methods that do access checks (Method.invoke,
> Constructor.newInstance, Field.set, ...) have always specified IAE.
> Compliant implementations have always implemented these checks. So there
> is nothing really here. Core reflection has been loosened slightly so
> that it assumes readability but it is otherwise aligned with the Java
> Language and bytecode.

I find your account of the specification to be very misleading then. Of
course code employing reflection has to protect against IAE because the
methods it uses include it as a checked exception. But the core
reflection API is also specified to provide setAccessible and it has
always been possible to rely on that method to ensure that IAE does not
actually get thrown in a large and well-defined set of cases.

To describe a severe reduction of that set of cases with the words
"there is nothing really here" seems to be even more misleading than
your partial account of the specified API. Given that this has been the
topic of intense discussion and debate here for the last few months I
find it hard to understand how you expect to wave it away with such
light words. Perhaps it would be better if you provided those who are
concerned by this change with a better account of why it really is
needed -- or maybe even considered working towards some more limited
change that attempt to meet both their needs and yours.

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

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

[Alan Bateman]

On 26/09/2016 10:28, Andrew Dinn wrote:


:
I'm sorry, Alan ,but I think that is disingenuous. When we see "access
control" on this list all of us really ought to bear in mind what have
been the de facto access control mechanisms for many JDK releases and
many more years. There are two such levels of control and one of them is
the security manager. That's a historic fact. Your statement above reads
very much like an attempt to hijack the discourse by hijacking
terminology so it addresses the topic you want to talk about (there is
no imputation of such a motive here -- I'm just reporting how it looks).
I was simply pointing out that when we are discussing access control 
here then we're talking about the access control that is enforced by the 
Java Language and VM.  No new terminology.


It is unfortunate that the legacy security manager mechanism also uses 
the term "access control" but it's completely different mechanism that 
is not relevant to anything we are doing here.




:
Has this really been the specification? If so then many years of
differing practice as regards the implementation have made that
'putative' specification worth less than the paper it is (probably no
longer :-) printed on.
The core reflection methods that do access checks (Method.invoke, 
Constructor.newInstance, Field.set, ...) have always specified IAE. 
Compliant implementations have always implemented these checks. So there 
is nothing really here. Core reflection has been loosened slightly so 
that it assumes readability but it is otherwise aligned with the Java 
Language and bytecode.


-Alan

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

[Stephen Colebourne]

Having read this proposal a number of times, and considering how the
talks explained things at JavaOne, I have come to the conclusion that
this proposal is too complex. FWIW, I like the idea that a module
should be able to declare that it needs reflective access from its
users, however given that the proposal is what results from the idea,
it doesn't seem as appealing as it should.

The reason why I put forward the exports/exposes approach [1] is that
it keeps the questions that must be asked when creating a module
simple:
- what do I depend on publicly (requires)
- what do I publish publicly (exports)
- what do I publish privately (exposes)

>From a security point of view it also seems that it should be the
responsibility of a module to allow the publishing of its private
details, and simply depending on another module seems very minimal
(and easy to miss) as a mechanism to allow that extra permission.

Stephen

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009370.html


On 21 September 2016 at 17:39, David M. Lloyd  wrote:
> 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) 

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

[Alan Bateman]

On 26/09/2016 04:50, GREGG WONDERLY wrote:


I still, like others seem to, find it amazingly odd, that the security manager, 
existing basis for access control is not still what would count.  I understand 
that the JDK itself is not deployed with a security manager impl in most cases, 
and thus there would be no access context for the security manager to be used 
against.  What’s odd, is that you are still trying to block access to 
reflective access to the “open JDK”.  If it’s really open and it’s really 
something that the community contributes to, why do we need to block access, 
hide details and otherwise obfuscate access details?  Modularization should 
just be about separating pieces not needed should it not?  Why has this 
degenerated into such a huge bit of access restriction too?
When you see "access control" in mails on this list then think the 
access control specified by the Java Language Specification and Java 
Virtual Machine Specification. It's nothing to do with the legacy 
security manager mechanism.


As regards core reflection then keep in mind that it has always been 
specified to do the same access checks as the Java Language and VM. It 
should not be a surprise if you get IllegalAccessException when 
attempting to access something when the equivalent Java code does not 
compile or where the equivalent bytecode would fail with IllegalAccessError.



:

For a long time, I have had conversations with a lot of different Sun, and now 
Oracle employees.   I think that they all want to enable great things to happen 
with the Java platform.  But the attempts at perfection and control involved in 
many of the JSRs (NIO2’s failure to provide a working, dependable filesystem 
observer for all platforms for example)
I can't tell what you mean here but if you are looking to interpose on 
file system operations then that support has been there since Java SE 7. 
If you mean the Watcher API then there is a platform independent 
implementation in OpenJDK. In any case, the nio-dev list is the place 
for to being gripes in this area.



  which have resulted in only partial improvements and in many cases reduced 
penetration (java.util.logging still doesn’t get improvements to align it’s 
apis better with varargs and more brief API designs)
It's not clear to me that it's worth doing a lot of the j.u.logging API 
but keep in mind that there were updates to modernize it a bit in Java 
SE 8 (Logger has methods that take a message Supplier for example). Also 
with JEP 264 then you have a way to plugin in your preferred logging 
framework to consume logging from the platform. The core-libs-dev list 
is the place to bring gripes or issues on logging.


-Alan

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

[GREGG WONDERLY]

I still, like others seem to, find it amazingly odd, that the security manager, 
existing basis for access control is not still what would count.  I understand 
that the JDK itself is not deployed with a security manager impl in most cases, 
and thus there would be no access context for the security manager to be used 
against.  What’s odd, is that you are still trying to block access to 
reflective access to the “open JDK”.  If it’s really open and it’s really 
something that the community contributes to, why do we need to block access, 
hide details and otherwise obfuscate access details?  Modularization should 
just be about separating pieces not needed should it not?  Why has this 
degenerated into such a huge bit of access restriction too?

Could people who think that modularity should solve these problems and the 
security manager not be part of the solution please provide some details about 
how security is the modularization mechanisms responsibility and not the 
security managers?  For deployment, I’ve always used the security manager to 
limit/control access when I take some 3rd party code/jar and deploy it into a 
production environment.  That helps me restrict its access to resources in a 
manageable and maintainable way.

What I see happening, is that this single issue of “access” to pieces of 
software, from other pieces of software is degenerating into huge amounts of 
complexity and specification and release control, which isn’t really what makes 
“open software” work together.

The conversation below, I feel, illustrates how big of a freight train of focus 
this single issue has degenerated into.  David tries hard here to be brief it 
seems, but arguably, there is so many specifics of variability and lack of 
ability to fully specify detail, that it’s hard to imagine, at least for me, 
how this path can result in anything more than “pseudo science” of 
specification and detail which will then result in a really hard to manage path 
forward, because there will still be no clean, clear and fully specified 
solution.

This is stuff that’s hard to detail, and even harder to managed with a “fixed” 
specification.  In the end, I am still concerned that what is happening, is 
something very specific to what the JDK team feels they need to do, to keep 
people out of private implementation.  It seems like that would best be done 
with a runtime security implementation, specific to the JVM, instead of a 
modularization specification which provides so many restrictions for open 
software systems that we end up only being able to say “all” or “nothing” is 
what we need to support.  The JDK needs more than that, but it’s only because 
developers at Oracle are being obstructionist to use of software that they 
don’t feel should be used.  

For a long time, I have had conversations with a lot of different Sun, and now 
Oracle employees.   I think that they all want to enable great things to happen 
with the Java platform.  But the attempts at perfection and control involved in 
many of the JSRs (NIO2’s failure to provide a working, dependable filesystem 
observer for all platforms for example) which have resulted in only partial 
improvements and in many cases reduced penetration (java.util.logging still 
doesn’t get improvements to align it’s apis better with varargs and more brief 
API designs) into new projects demonstrates for me that there is not always the 
right focus on what needs to happen in actuality, and instead a shotgun 
approach that destroys a lot of opportunity and splatters things around making 
them visible without great, ongoing improvement.

How can we make sure that this work doesn’t just result in a complete melt down 
of open software, causing huge migration to Harmony or Wine or some other Java 
platform abandonment?  I know that seems far fetched, but software developers 
are never really interested in friction, going slower, or working harder to 
deal with new features.   

Gregg

> On Sep 21, 2016, at 11:39 AM, David M. Lloyd  wrote:
> 
> 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