This is definitely a problem with web apps. (I have heard from other teams, but not experienced it myself.) Wouldn't the correct solution be to make the array use weak references? Of course, if it makes sense to expose more of the api (I'm not familiar with it), then do that, too.
Joel -----Original Message----- From: core-libs-dev-boun...@openjdk.java.net [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Roman Kennke Sent: Wednesday, December 22, 2010 9:36 AM To: core-libs-dev@openjdk.java.net Subject: Potential memory leak in java.util.logging.Level 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? 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.
