On 07/12/2016 11:07 AM, John Rose wrote:
On Jul 12, 2016, at 9:00 AM, John Rose <john.r.r...@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
