<AWT Dev> Accessing internal packages in JDK 9

[Phil Race]

PS .. when you identify a workaround that you think
bears a resemblance to the required fix, you could
submit it as a patch. That way you won't lose track
of the issues and it has a good chance of being fixed
sooner.

-phil.

On 7/27/15 4:22 PM, Phil Race wrote:
> 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
>>>
>>>
>>
>