On May 23, 2011, at 6:45 AM, Tom Hawtin wrote: > On May 22, 10:19 am, Kirk <[email protected]> wrote: > >> For example, if you have a application class implementing an interface from >> the bootstrap classloader, it is possible that this relationship, which is >> expressed in the object reference chains, will keep your classes metadata >> live. Because your class is live, the classloader that loaded it will be >> live. Since the classloader is live, *all* of the classes referenced by that >> classloader will be kept live. Which means in the context of an application >> server, that products logic may "unload" an application and reload the new >> version but that intricate little reference chain from the bootstrap >> classloader (or the extension or the application or another tiered loader) >> will prevent everything from being GC'ed. > > Wouldn't that mean that class loaders are effectively never collected, > which doesn't appear to be true.
Classloaders are often not collected. > There are ClassLoader leaks > associated with the Java libraries, including ThreadLocal, JDBC > DriverManager and Java Beans. Yup, Tomcat leaks on a Swing class. Regards, Kirk > > Tom Hawtin > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
