ClassLoader Leak test framework in Maven

Today I launch another weapon in the ongoing war on Classloader Leaks: The classloader-leak-test-framework. Admittedly, the framework itself is not new. The news is that in order to use it you no longer have to clone the Git repo, because it is now available as a Maven artifact through Maven Central.

If you want to confirm a suspected leak, just add


to your POM and create a test case that you believe would trigger the leak. (Make sure to check GitHub for the current version.)

Heap dump when leak detected

Another improvement to the test framework that I have not previously announced, is that the framework can now automatically create a heap dump when a ClassLoader leak is detected. This makes it even easier to track down the cause of the leak and determine the required countermeasures. To activate this feature add @Leaks(dumpHeapOnError = true) to your test method.

Test framework documentation

For further information on how to use the ClassLoader Leak test framework, see the projects space on GitHub.

Counterproductive security: disable password paste

I saw it again today – a site where they had made the effort to disable pasting your password into the login form. The motive surely must be to increase security, but this may be the stupidest, most counterproductive security measure I know of. Let me explain why.

Basic password principles

The two most basic principles when it comes to online passwords are:

  1. Use strong passwords
  2. Do not use the same password on multiple sites

One reason for using a strong password is obvious – it should not be easy to guess your password (i.e. pet’s name etc). The less obvious reason is that long and complex passwords are harder for hackers to reveal using simple techniques like dictionary attacks. If you want to know more about creating strong passwords, just google it. But I have another suggestion below.

The reason not to use the same password on multiple sites, is that in the unfortunate – although not that uncommon – event that a site gets hacked, and that they stored the passwords in clear text or weakly hashed without salt (don’t be that guy), so hackers get hold of your login info, they should not be able log into all your other accounts. Just imagine some low profile (low security?) forum you may have posted in once or twice gets hacked, and suddenly someone can control both your Google/Apple, Facebook and LinkedIn account. Not a pleasant thought, huh? (Tip: Enable two-factor authentication!)

Password managers to the rescue

The easiest way to use strong, unique passwords for all your online accounts is to use a password manager and have it generate different, strong, random password for each site. Thanks to the password manager, you can have good passwords like ltAaxjykylfcq3yU1K9M for Site A and 8KtVtz2iKa0kEhJ6honf to Site B, without having to remember any of them. (But you will of course need to remember the – preferably – strong password to your password manager. This is where the tips for manually creating strong passwords come in handy!)

I personally use and highly recommend KeePass which is free and available on multiple platforms (so you can access your passwords on both your PC and your smartphone). In my KeePass file I have 400+ passwords, most of them with a complexity like the examples above. Even though my memory often serves me well, there is just no way I could ever remember 400+ passwords as strong as ltAaxjykylfcq3yU1K9M.

Counter productive paste disablement

Back to the problem with disabling pasting of passwords into the login form. The most straighforward way to use KeePass, is to open your safe file and then just copy/paste your password into the login form. You won’t even see the password, as KeePass will by default mask it. The problem with sites that have disabled pasting into the password field, is that they discourage the use of password managers. Admittedly there are other ways to use password managers, such as browser integration and drag-and-drop, but the average user probably won’t bother to set that up. So, if I can’t copy/paste ltAaxjykylfcq3yU1K9M from KeePass (and don’t know there are other options), which do you think is the most likely scenario: that I unmask the password in KeePass (which by the way could allow someone reading it over your shoulder) and type it in manually – or that I choose a password that is easier to remember and type, say maybe one of the most popular passwords in the world…? And do you think that it is more or less likely that the user will reuse the same password on multiple “paste disabled sites”, than “paste enable sites”? So by discouraging the use of password managers, do you agree these sites implicitly discourage the two basic principles for online passwords – strength and uniqueness?

If you are a developer, please don’t disable paste in your login form.

ClassLoader Leak Prevention library version 1.13.0 released

Version 1.13.0 of ClassLoader Leak Prevention library has just been released, and should propagate to Maven Central shortly.

This version changes the treatment of threads that uses the web apps ClassLoader as its contextClassLoader, while neither the Thread nor its Runnable are loaded by that ClassLoader. Previously the library would kill such Threads, assuming the ClassLoaderLeakPreventor.stopThreads setting was not explicitly disabled, which caused issues with Tomcat 7 executors.

Grab the new version via Maven central or download the jar manually.


ClassLoader leaks at JavaForum Stockholm

Tonight I did a presentation on ClassLoader leaks at JavaForum Stockholm.


Unfortunately there were some issues with the video feed, so I turned off the recording to rule out that interfering with things. Apparently the organizers recorded the event, so watch this space for updates when it has been made available online. Until then you may check out the recording of the same presentation from an earlier event:


Slide 26: Heinz Kabutz Java Specialists’ Newsletter The Law Of The Blind Spot
Slide 41: Tomcat Bugzilla entries #48895 and #49159.

ClassLoader Leak Prevention library version 1.12.0 released

Version 1.12.0 of my ClassLoader Leak Prevention library has been released.

Apart from internal improvements (thanks to Jeremy Landis) it contains the following features:

  • Invoke org.springframework.web.util.IntrospectorCleanupListener in case it exists on the classpath. (Thanks to Craig Andrews)
  • Unregister ImageIO Service Provider loaded by the web application class loader. (Thanks to Thomas Scheffler)
  • Improve prevention of leaks caused by sun.awt.AppContext

Grab the new version via Maven central or download the jar here.


ClassLoader Leak Prevention library version 1.11.0 released

Version 1.11.0 of my ClassLoader Leak Prevention library has been released.

Apart from minor tweaks it contains the following features:

Grab the new version via Maven central or download the jar here.


ClassLoader Leak Prevention library version 1.10.0 released

Version 1.10.0 of my ClassLoader Leak Prevention library has been released.

Apart from minor improvements it contains protection against a leak caused by Caucho Resin version < 4.0.40. It is however recommended that you upgrade to Resin 4.0.40+.

Grab it via Maven central or download the jar here.


ClassLoader leaks at JavaForum Gothenburg

Tonight I have talked about ClassLoader leaks at JavaForum Gothenburg. Below you will find the slides from the presentation, the link to the Leak prevention library on GitHub and links to all the parts of the blog series I made on the subject.



Heinz Kabutz Java Specialists’ Newsletter The Law Of The Blind Spot referenced on slide 26.
Tomcat Bugzilla entries #48895 and #49159 referenced on slide 41.

Leak prevention library

GitHub project

Links to all parts in blog series

Part I – How to find classloader leaks with Eclipse Memory Analyser (MAT)

Part II – Find and work around unwanted references

Part III – “Die Thread, die!”

Part IV – ThreadLocal dangers and why ThreadGlobal may have been a more appropriate name

Part V – Common mistakes and Known offenders

Part VI – “This means war!” (leak prevention library)

Better compareTo() syntax

I’ve never really been a big fan of the syntax of java.lang.Comparable.compareTo(). For some reason I find myself constantly referring to the JavaDocs to remind me whether < 0 or > 0 means the argument is less vs more than the callee.

So I decided to do something about it, and created a minimal API with the sole purpose of improving readability of compareTo().

The API supplies methods in two flavors, expressive or abbreviated. The expressive version looks like this:

import static;

  boolean oneIsZero = is(1).equalTo(0);
  boolean aIsNotZero = is(a).notEqualTo(0);
  boolean bIsZero = is(b).zero();
  boolean value1LessThanValue2 = is(value1).lessThan(value2);
  if(is(a).lessThanOrEqualTo(b)) {

  boolean date1AfterDate2 = is(date1).greaterThan(date2);

  if(is(a).greaterThanOrEqualTo(b)) {


The abbreviated syntax looks like this:

import static;

  boolean oneIsZero = is(1).eq(0);
  boolean aIsNotZero = is(a).ne(0);
  boolean value1LessThanValue2 = is(value1).lt(value2);

  if(is(a).le(b)) {

  boolean date1AfterDate2 = is(date1).gt(date2);

  if(is(a).ge(b)) {


The API is available on Maven Central:


Source are on GitHub.

Manual download here.

Debugging third party libraries with AspectJ and Maven

Once in a while you may find yourself in a situation, where you need to debug a third party library on a production server or other environment where it is not possible or impractical to attach a debugger. It may also be the case that modifying the sources of that library and compiling a custom version is not an option (due to compilation dependencies, licenses, source not available or whatnot).

I found myself in such a situation a while back when I needed to understand memory leaks in OpenOffice JURT. I achieved this by injecting debug logging into the library with AspectJ, and in this post I will describe how.

In my situation the third party library was a transitive Maven dependency. In order to weave this library with my own aspects, I added this to the pom.xml:

          <!-- Weave third party dependency -->
        <!-- Weave on compile -->

Note! In order for the weaved version of the library to be included in your .war, the above should be located in the web module if your Maven project has multiple modules. If your aspect is in another module you also need to add


to the configuration.

You’ll likely also want to add the AspectJ runtime dependency, for the aspect implementation.


Now lets move on with the actual aspect. If you need an introduction to AspectJ, you may find this post useful. First we have our aspect class:

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

 * AspectJ aspect used for debugging memory leaks caused by OpenOffice JURT
 * @author Mattias Jiderhamn
public class JURTDebugAspect {
  private static final Logger LOG = LoggerFactory.getLogger(JURTDebugAspect.class);

  /** Utility method to get StackTraceElement of caller */
  private static StackTraceElement getCaller(int levels) {
    StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();
    return stackTrace[levels + 1];


Inside that aspect class, we can add different joinpoints and advice to inject logging.

  public void addCalled() {
    LOG.warn("JURT: add() called by " + getCaller(3));

This will log calls to the third party API add() method, including calls from other third party libraries. Note that “execution” pointcut is used rather than “call” pointcut, since we are weaving the callee, not the caller. The getCaller() utility method also allows us to see what code called the add() method.

  @Before("call(* java.lang.Thread.start(..)) && within(*) && target(thread)")
  public void threadStarted(Thread thread) {
    LOG.warn("JURT: Thread.start() called by " + getCaller(2) + " on thread named " + 
      thread.getName() + " of type " + thread.getClass().getName());

Here we add some logging for when the third party library calls the start() method on java.lang.Thread, and include the name and type of the started thread.

  @Around("call(*$ && within(*) && target(job)")
  public Object jobRun(ProceedingJoinPoint proceedingJoinPoint, Object job) throws Throwable {"JURT: starting: " + job.getClass().getName() + " in thread " +
    final long start = System.currentTimeMillis();
    try {
      return proceedingJoinPoint.proceed();
    finally {"JURT: done: " + job.getClass().getName() + " in thread " +
        Thread.currentThread().getName() + "; took " + 
        (System.currentTimeMillis() - start) + " ms");

Here we log internal calls to inside the API, and measure the time that those calls take. The name of the Job subclass is included.

Good luck debugging third party libraries!