(original) (raw)

I agree with John on this. There's also a third point:

3\. Java 9 (and later releases) still load jar files. Unless specialization is restricted to modules, relying on module boundaries for security isn't sufficient.

Purely from an implementation perspective, I'd rather do a pointer comparison then a larger guid comparison. And I'd rather debug something with a name than matching guids.

--
Bjørn Vårdal

----- Original message -----
From: John Rose
To: Peter Levart
Cc: Brian Goetz , Bjorn B Vardal/Ottawa/IBM@IBMCA, valhalla-spec-experts@openjdk.java.net
Subject: Re: Nestmates
Date: Thu, Feb 18, 2016 1:10 PM

On Feb 17, 2016, at 12:15 PM, Peter Levart <peter.levart@gmail.com> wrote:

Suppose javac generates a random nest id for each nest (say 128 bit UUID). Two classes are nest-mates if they belong to the same module \*and\* share the same nest id.

There are two parts to this proposal:

1\. New naming convention for nests, based on UUIDs. This is a new concept in the JVM, and would require new infrastructure to manage (generate, transcode, verify, reflect, debug). That means new bugs and new attack surfaces. In the absence of a decisive benefit, it's better to reuse existing name spaces, and (in particular) the JVM's type name dictionary.

2\. Unidirectional links. The UUID, being a pure identity with no content, does not contain a list of its nestlings. The nestlings point to the nest (via the UUID). Any class can inject itself into a nest (in the same package) simply by mentioning the appropriate UUID. Unidirectional linkage means that there is no way to enumerate a nest. This complicates some optimizations (based on sealed types). Security and seal-ability of nests is reduced to that of packages. PRIVATE becomes just an alias for default-scope access control.

Sorry, but neither part of this is appealing to me, compared with the current proposal.

— John