Proposal: #ReflectiveAccessToNonExportedTypes (revised) & #AwkwardStrongEncapsulation: Weak modules & private exports

[mark.reinhold at oracle.com]

2016/10/12 1:45:16 -0700, Tim Ellison <tim_ellison at uk.ibm.com>:
> mark.reinhold at oracle.com wrote on 11/10/2016 16:14:14:
>> ...
>> 
>> I've read Colebourne's proposal [1], and I can see its intuitive appeal
>> to developers (like us!) who are used to thinking about all these things.
>> To a new developer it might be easier to explain his `exposes *` than the
>> above `exports private *`, but I think explaining weak modules is even
>> easier.  A new developer is likely to hear the "reliable configuration +
>> strong encapsulation" mantra fairly early on, and weak modules are simply
>> the former, without the latter.
> 
> I disagree.  I like the Colebourne's approach because it keeps to two 
> declarations ('exports' and 'exposes') as orthogonal concepts.  However,
> I don't see the need to open the syntax up for wildcards '*' at this time.
> 
>> A couple of other problems I see with Colebourne's approach:
>> 
>>  - The only way to allow an exported API package to be used reflectively
>>    is to expose it for deep reflection.  That requires typing another
>>    directive and, worse, makes the internals of that package available
>>    for deep reflection, which is probably not what was intended.

(For the record, Colebourne later pointed out that this is not what he
 intended [1].)

>>  - The interactions between `exports`, `exposes`, and the qualified
>>    forms of these directives turns out to be pretty complicated once you
>>    work out all the cases.  (We've done this internally, for a somewhat
>>    similar proposal that allows both `private` and `dynamic` modifiers
>>    on the `exports` directive.)  They wind up being nearly as bad as the
>>    existing rules for protected members [2].  I'm not convinced that
>>    this relatively small bit of expressive power is worth the additional
>>    complexity.
> 
> It would be interesting to see that exploration exposed, because as you 
> say the Colebourne expression appears intuitive.

On further examination my second statement above turns out not to be
true, especially if you simplify things by avoiding wildcards.

> As discussed, it would be useful to explore the options for changing the
> proposal's constraint that you can't "expose" a package for reflection 
> without also exporting it.

I've written up a new proposal intended to address this which I'll post
in a moment, along with an analysis of the proposals presented thus far.

- Mark


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