Bozhidar Bozhanov

About Bozhidar Bozhanov

Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of Computoser and Welshare. Worked on Ericsson projects, Bulgarian e-government projects and large-scale online recruitment platforms.

Augmenting 3rd-Party Libraries

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

  • 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.
 

Reference: Augmenting 3rd-Party Libraries from our JCG partner Bozhidar Bozhanov at the Bozho’s tech blog blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

2 Responses to "Augmenting 3rd-Party Libraries"

  1. Philipp Schneider says:

    Nice article.
    Github is a great way of forking third-party libs and extend/bugfix them.

  2. Pray to the class loader? I hope it was just a joke. Instead make sure your version of the class(es) appears first on the class path (of that loader) before lib’s version.

Leave a Reply


five − 3 =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close