It's not too late for access control

[David M. Lloyd]

On 07/12/2016 11:07 AM, John Rose wrote:
> On Jul 12, 2016, at 9:00 AM, John Rose <john.r.rose at oracle.com> wrote:
>>
>> lurk mode
>
> P.S. I forgot one more point:  As JVM/JIT guy I find the prospect of sealing
> packages very appealing.  Maybe it's a false promise, but it would be a
> home run if we could reliably seal sub-assemblies for tree-shaking AOT
> compilation.  Doing this requires pretty strong assurances that the AOT
> engine can enumerate all uses of a "public" class.  Doesn't this use case
> interfere with the proposed principle that "public always means global"?
> Again, it's a tug-of-war between the class author and an assembly-time
> operation.

I'm definitely sympathetic to the AOT argument.  However there is 
absolutely no difference in the guarantees that can be derived from the 
Jigsaw proposal versus my proposal.  Consider these cases:

1) A package is intended to be completely internal and is not exported; 
in Jigsaw, the types in this package would be public, and in my proposal 
they would not be.
2) A package is intended to be shared to certain targets; same as above.
3) A package is meant to be accessible to all; in both cases the types 
would be public; in the Jigsaw case it would have to be additionally 
exported to all.

In all three of these cases, AOT compilation would have to assume that 
this linkage-oriented information would not change between compile and 
assembly, and in all three of these cases, this assumption can be 
trivially defeated by an even mildly determined user.  So in the end, it 
seems to me that AOT is something that would have to be entered into 
with open eyes by the users, and all phases would have to be conscious 
of additional restrictions required to execute a stable run-time image.

-- 
- DML