The jdeps tool bundled with current JDK 8 updates should help
you produced a definitive list - of your current uses.
A web page about jpdeps and current recommended replacements for
some internal APIs can be viewed at
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
jigsaw-...@openjdk.java.net is the list for the project under which the
changes are being made, and folks there are probably aware of any
likelihood of some of the non-client ones getting a replacement.
I don't know how a classloader can prevent a dll being unloaded unless
you have tied a call to dlclose into the classloader gc process yourself.
Can you explain this more ?
I do not see any likelihood of the client ones you list being made public.
Some of them are very deep in the details of the implementation.
A more viable line to file bugs describing where the leakage is - and/or
point us to any bugs that are already filed on these.
-phil.
On 07/27/2015 01:15 PM, Simon Nash wrote:
I have recently discovered that applications will no longer be able
to access internal packages (sun.* and com.sun.*) in JDK 9. This is a
major problem for my application as it requires access to some internal
packages in order to work correctly.
In most cases, my need to access these internal classes is to work around
"object leakage" in Swing that results in objects being created and held
by Swing with no means of freeing these objects by any application
action.
In some cases, these "leaked" objects reference my application
classloader
via their protection domain, and this means that my application
classloader
cannot be garbage collected even if I remove all references to it from
within my application. My application uses native DLLs that sometimes
need
to be replaced by new versions and these DLLs cannot be unloaded and
reloaded unless the application classloader that loaded these DLLs has
been
garbage collected.
The only workaround I have found for this problem is to use internal APIs
together with reflection to locate the fields that are holding these
internal "leaked" objects and set these fields to null.
It is hard to provide a definitive list of all the internal packages that
I need because the list tends to grow each time I use additional Swing
functionality in my application. At present, the packages are:
sun.awt.AppContext
sun.awt.image.MultiResolutionToolkitImage$ObserverCache
sun.awt.X11.XBaseWindow
sun.lwawt.LWComponentPeer
sun.java2d.pipe.BufferedContext
sun.java2d.pipe.RenderQueue
sun.java2d.pipe.hw.BufferedContextProvider
In addition, my application is using some APIs from internal packages to
access functionality that isn't available via official APIs. These aren't
Swing or AWT packages, so this mailing list probably isn't the right
place
to go into details. Any suggestions for the correct list(s) to raise
this
issue would be appreciated. The packages are:
com.sun.management.HotSpotDiagnosticMXBean
sun.misc.Signal
sun.misc.SignalHandler
sun.nio.ch.ChannelInputStream
Best regards,
Simon Nash
