mark.reinh...@oracle.com wrote:
2015/8/4 12:07 -0700, Simon Nash <si...@cjnash.com>:
mark.reinh...@oracle.com wrote:
2015/8/4 11:34 -0700, si...@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
