Hi Chris, (Sorry for top-posting, my stupid email program cannot do proper quoting)
I don't understand why the CR is a 'request for enhancement' with 'very low' priority. A memory leak should be a bug with at least high priority in my world view. I will see if I find time to implement a fix. **Roman -----Original Message----- From: Chris Hegarty [mailto:chris.hega...@oracle.com] Sent: 22 December 2010 17:35 To: Roman Kennke Cc: core-libs-dev@openjdk.java.net Subject: Re: Potential memory leak in java.util.logging.Level On 12/22/10 02:36 PM, Roman Kennke wrote: > Hello, > > I believe java.util.logging.Level is potentially memory leaking. This can > happen if an application defines its own subclass of Level and is loaded by > its own classloader. Level's constructor adds a reference to the new instance > of the subclass to its 'known' ArrayList (which is a static field). This > instance is never removed from that list. And since this instance holds a > reference to its classloader, this means that no classes loaded by that > classloader can be unloaded. It could be argued that you should not do crazy > stuff with classloaders, but this happens invariably when you deal with > applets. I guess similar problems can arise on app servers as well. > > I wonder why Level's constructors need to be protected though. If they were > public, and new Levels could be created simply by instantiating one, this > whole problem would not exist. Then the Level.known list would only reference > instances of its own class, which would be problematic, unless you create > LOTS of levels, which is unlikely. I don't like static collection fields > anyway... too prone to leaking. > > Is this a known problem? Is there a solution to this, except not creating > custom log levels? How else could custom log levels be created under those > circumstances that would not trigger this problem? This would appear to be a known issue, see CR 6992761 [1]. -Chris. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6992761 > > Thanks, > Roman > This communication is for informational purposes only. It is not > intended as an offer or solicitation for the purchase or sale of > any financial instrument or as an official confirmation of any > transaction. All market prices, data and other information are not > warranted as to completeness or accuracy and are subject to change > without notice. Any comments or statements made herein do not > necessarily reflect those of JPMorgan Chase& Co., its subsidiaries > and affiliates. > > This transmission may contain information that is privileged, > confidential, legally privileged, and/or exempt from disclosure > under applicable law. If you are not the intended recipient, you > are hereby notified that any disclosure, copying, distribution, or > use of the information contained herein (including any reliance > thereon) is STRICTLY PROHIBITED. Although this transmission and any > attachments are believed to be free of any virus or other defect > that might affect any computer system into which it is received and > opened, it is the responsibility of the recipient to ensure that it > is virus free and no responsibility is accepted by JPMorgan Chase& > Co., its subsidiaries and affiliates, as applicable, for any loss > or damage arising in any way from its use. If you received this > transmission in error, please immediately contact the sender and > destroy the material in its entirety, whether in electronic or hard > copy format. Thank you. > > Please refer to http://www.jpmorgan.com/pages/disclosures for > disclosures relating to European legal entities.
