2015/8/5 3:29 -0700, Simon Nash <si...@cjnash.com>: > mark.reinh...@oracle.com wrote: >> I understand the problem you're solving, but the difficulty with this >> as a category is that it arguably includes every internal class, even >> those never intended to be even internal APIs, since pretty much any >> internal class can declare a field that winds up retaining some object, >> somewhere, unnecessarily. If we were to take this on as a category in >> the context of JEP 260 then we'd wind up encapsulating very little. > > I wasn't suggesting that this is a reason for not doing encapsulation but > rather that this requirement exists and implies the ongoing need for a > "last resort" mechanism to bypass encapsulation.
Understood. > This mechanism shouldn't > be regarded as a transitional requirement but as something that will still > be needed after new public APIs have been created to replace the private > APIs that are known to be required by application developers. I don't think the "last resort" mechanism is in any way transitional. There will always be legitimate -- though hopefully rare -- reasons to break through encapsulation boundaries from the command line. - Mark
