[SPAM?] Re: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.)

[mark.reinhold at oracle.com]

2015/8/5 3:29 -0700, Simon Nash <simon at cjnash.com>:
> mark.reinhold at 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