Use of internal APIs to protect against memory leaks

[Alan Bateman]

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