> 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
