<AWT Dev> Accessing internal packages in JDK 9

[Simon Nash]

Phil Race wrote:
 > The jdeps tool bundled with current JDK 8 updates should help
 > you produced a definitive list - of your current uses.
 >
Thanks for your quick reply.  I will run this tool to check that my list
is complete and correct.

 > 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
 >
I will look at this to see if it helps with my issues.

 > 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 will raise this topic on that list.

 > 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 ?
 >
See the section "Library and Version Management" in this document:
http://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/invocation.html
Specifically:

(1) The same JNI native library cannot be loaded into more than one class
loader.  Doing so causes UnsatisfiedLinkError to be thrown.

(2) In addition, native libraries can be unloaded when their corresponding
class loaders are garbage collected.

Because of (1), a new version of the native library can't be loaded until
the old version is unloaded.  Because of (2), the old version can't be
unloaded until the original classloader has been garbage collected.  I have
not tied anything into the classloader GC process myself.

 > 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.
 >
Will there be any way to access these if they are not public (for example,
by reflection)?  If this is possible, I should be able to adapt my current
workaround code to run on JDK 9.

 > 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.
 >
Some have existing bugs filed (6575402, 8029147) and many others don't.
To file bugs on everything I have found would be a huge effort because I
discovered these some time ago and my memory of the exact details has
faded by now.  The only way to be sure I have the details correct would be
to remove my workarounds and analyse the leakages again using JVisualVM.
This would require several weeks of work.

At present, a developer can work around a bug like this until a fix is
available in a new version of the JDK.  If access to private classes is
removed completely, such workarounds will no longer be possible.

  Simon

Phil Race wrote:
> 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
> 
>