Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.)

[mark.reinhold at oracle.com]

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.

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