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
Bjørn Vårdal
----- Original message -----
From: John Rose <[email protected]>
To: Peter Levart <[email protected]>
Cc: Brian Goetz <[email protected]>, Bjorn B Vardal/Ottawa/IBM@IBMCA, [email protected]
Subject: Re: Nestmates
Date: Thu, Feb 18, 2016 1:10 PM
On Feb 17, 2016, at 12:15 PM, Peter Levart <[email protected]> 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
