<AWT Dev> Accessing internal packages in JDK 9

[Phil Race]

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-dev at 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