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

[Simon Nash]

mark.reinhold at oracle.com wrote:
> 2015/8/4 12:07 -0700, Simon Nash <simon at cjnash.com>:
>> mark.reinhold at oracle.com wrote:
>>> 2015/8/4 11:34 -0700, simon at cjnash.com:
>>>> Thanks for this.  In the list of broad categories, one is missing:
>>>>
>>>> x  Those which are required to enable application code to work around
>>>> bugs in the JDK such as leaked objects.
>>> That could be an awfully broad category.  Do you have some specific
>>> examples in mind?
>> It is a broad category and it is an important one that deserves mention.
>>
>> I have come across a number of examples of leaked objects in Swing/AWT for
>> which I have implemented workarounds by using internal APIs and reflection
>> to locate the relevant fields and set them to null.  At some point, I hope
>> to create formal bug reports for these.
>>
>> The main impact is not memory consumption but the holding of references
>> to my application classloader that prevents it from being garbage collected.
>> This prevents any native libraries that were loaded by this classloader
>> from being replaced with updated versions.
> 
> 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.  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.

> A better approach here would be to fix the actual bugs, so bug reports
> would be most welcome (especially if they include suggested fixes).
> In the meantime you'll be able to use the last-resort command-line
> workaround to keep your existing code running.
> 
> - Mark
> 
I agree, but it is unrealistic to think that all such bugs will be fixed
promptly and no new ones would ever appear.  For example, bug 6575402 has
been open since 2007 and bug 8029147 has been open since 2013.  Just one
leaked object causes the application classloader not to be garbage
collected and its native DLLs not to be unloaded.  This is why it will
always be necessary to have some escape mechanism by which application
developers can work around such issues.

  Simon