<AWT Dev> Accessing internal packages in JDK 9

[Phil Race]

On 07/27/2015 03:56 PM, Simon Nash wrote:
> 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:
>

So these dlls contain JNI code .. and need to be found by the VM.

I suspect that for client code there are few if any tests that really
exercise this.


> (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.

My understanding is that you would have to use  special command line options
but this is all a work in progress.

>
> > 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.

I believe it would be worthwhile to try to identify as many of these as 
possible.

-phil.
>
>  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
>>
>>
>