Augmenting 3rd-Party Libraries

For every project I’ve participated in, there has been a need for augmenting some third-party library. There are a few of reasons for this:

• There’s a bug
• There’s missing functionality
• There’s functionality that doesn’t work as you need it to

What do you do in these cases? Obviously, you report the problem or even suggest a fix. But until that goes into the next version, you need to get your work done. To do that, you have many options, depending on the severity of the situation and the quality of the library:

• Extend the problematic class (or inject a custom implementation of some piece into it) – that’s the best way, as it is a purely object-oriented approach and doesn’t require any hacks. But it’s possible only if the problematic library is of good quality and is designed for extension
  
  
• Get the sources, fix the problem, repackage the jar. That sounds like a nice approach, but it has some issues. If you use a dependency manager (and you should use one), it would need either installing the jar in a local repo, or using system scope + copy-dependencies plugin, or having a nexus installation and adding the jar there. The thing I dislike the most with this approach is that you don’t actually have the fix in your project – and you can’t quickly iterate when fixing it
  
  
• Use reflection to access some hidden parts of the library
  
  
• Extend a class, but copy-paste some methods that cannot be modified otherwise (because they are monolithic). I’ve done that many times, and although it’s a hacky approach, it is not that bad. Of course, try to minimize the copy-pasted code from the library.
  
  
• If you can’t use subclasses of the problematic class, then make your own versions with exactly the same name and package, and pray to the classloader to pick yours instead of the packaged ones (it usually does, but you should really test that on multiple environments)
  
  
• Use AspectJ or other bytecode “magic” to modify the behaviour of the problematic classes
  
  

Problems may occur when you upgrade the library, so watch out for that. The approach picked up should be the least hacky one, even if it requires writing a few Adapters and subclassing a couple of classes – always prefer writing an Adapter or plugging in a custom implementation to reflection or bytecode manipulation.

I’ve done most of the above things, depending on the urgency of the fix and the quality of the library. And while writing this post, I played a bit with java instrumentation, and came up with a very simple (and limited) tool, called quickfix – it allows you to replace a target method with a custom method of yours – just annotate it with @ReplaceMethod and specify the target to be replaced. This would work in rather simple scenarios (and you can do the same thing with AspectJ), but it may be handy sometimes, so feel free to try it and report problems.