Use of internal APIs to protect against memory leaks

[Phil Race]

 > For the 2D disposer issue then 2d-dev is the place to start

The 2d disposer has a call to Thread.setContextClassLoader(null)

It's been there since JDK6u21 ... and is in all later releases.

https://bugs.openjdk.java.net/browse/JDK-6936389

So there is no need I see for accessing this in JDK 9

-phil.

On 9/19/2014 9:19 AM, Alan Bateman wrote:
> On 19/09/2014 14:12, Mark Thomas wrote:
>> :
>>
>> The memory leaks stem from the generally more complex class loader
>> structure present in a JavaEE container than is typically present in a
>> standalone Java app.
>>
>> At this point, I have two questions.
>>
>> 1. Is this community interested in examining these memory leaks further
>> to see what can be done in the JDK to avoid them?
>>
>> 2. If yes, would you prefer a discussion thread for each leak or one
>> thread for all leaks? Personally, I think a thread per leak would be
>> easier to manage but it might make sense just to look at one leak first
>> as there may well be some common themes that emerge which would save us
>> discussing them on each thread.
>>
>>
> I agree with with your suggestion that a discussion per so-called leak 
> would be better than trying to discuss all of this in one thread. The 
> hard bit will be finding the right list to start the discussion. For 
> the AWT issues then awt-dev is the place to start. For the 2D disposer 
> issue then 2d-dev is the place to start. The security-dev list is the 
> place for the security library issues. The net-dev list for the 
> URLConnection  issue. I think core-libs-dev is probably okay for the 
> rest.
>
> Just to set expectations, it's possible that the outcome of some of 
> these will be just a bug in the JIRA. In some cases then I expect you 
> might get a bit of push back as there are performance and 
> compatibility issues to take account.  As an example, the 
> system-wide/singleton ORB returned by ORB.init should never be located 
> via the TCCL. However switching this to using the system class loader 
> breaks a number of 3rd party ORBs that freely cast between 
> per-application ORBs of whatever ORB is bundled with the application 
> and the system-wide ORB that acts as the type code factory. However in 
> general then having the JDK cache anything that is located via the 
> TCCL is a bug and I think you will get support for poking at those 
> issues.
>
> -Alan