Hot-fixing a bug in a third-party library dependency

Question

I found a minor bug in a bigger application framework that I am using. Fixing requires only to change two lines in a single class. I fixed the issue and pushed the changes to the project's repository.

However, I need to release tomorrow. Therefore, I cannot wait until the library is releasing a new version. I am wondering what would be the best way to integrate the patched version into my project:

• Build the project: This I find quite difficult, I cannot even build it properly since so many unit tests are broken in the snapshot repository and even without the unit tests I do not get very far since I am obviously missing some dependencies that cannot be found in Maven Central. Also, I need to send the fixed version along to every other developer since it cannot be found on Maven Central. (We work on the net and we do not have our own Nexus.)

• Adding a new module to my project where I keep a copy of the class that I have fixed. I then add this module as a dependency to all modules that should use the overriden version of the class. But how is the JVM determining which class it actually loads? It will find two jar-files that contain a class with the same name. Which one will it actually load? If I could make this work, this would allow me to integrate the modified version of the class with my project such that I could distribute the patch together with the project and once the bug gets fixed, I could simply remove the module.

• I am including the modified class file into the affected module itself. So far, this appears as the easiest solution to me since the JVM will always load the class from the same jar first. (Am I right? At least that is what I observed in my tests.)

Thanks for any input on this.

Answer 1

I ended up building the project separately and moving this version to another namespace. This is apparently not so uncommon. For example Hibernate keeps cglib in its own namespace in order to avoid version conflicts due to API changes.

• The first suggested solution had a problem when the project I used was also used in another dependency what led to that both my modified version and the normal version were on the class path what led to very strange behavior due to naming conflicts.

• The second and third suggestion had similar problems as the first suggestion. Additionally, I broke compatibility to other versions of the dependency.

Even it sounds painful: Moving out of the namespace and providing a seperate build is a must, even if you only change a few lines of code.

Answer 2

I think moving dependencies of your project into custom namespaces is not optimal, for several reasons:

• your modifications will likely not be sent back to the original developers of the dependency.
• it will be hard to keep up with new dependency versions, so no more bugfixes, no new features, no vulnerability fixes from third-party developers and contributors.
• my experience is that over time it gets forgotten how and why the custom namespaced dependency got modified. This will result in this part of the project being not only deprecated, but also untouchable, as no one will know what'll break when replacing it.

I agree that a workflow using Jitpack is the best solution. I wrote a blog post with a detailed guide for doing it with only a couple minutes of overhead: https://5am.technology/2016/12/fix-bugs-third-party-dependency-jitpack/

Answer 3

TL;DR;

Visit https://jitpack.io and read how it works

---

Steps to solve the problem

Supposing the third-party library is on github, simply clone the project, and fix it.

Then use https://jitpack.io. JitPack creates a .jar from your repo (where you fixed the code) and generates a dependency for you like

<dependency>
    <groupId>GITHUB_USER</groupId>
    <artifactId>REPOSITORY</artifactId>
    <version>COMMIT</version>
</dependency>

also you need to explicitly add this remote repository

<repositories>
    <repository>
        <id>jitpack.io</id>
        <url>https://jitpack.io</url>
    </repository>
</repositories>

• Fast work-around
• Simple to do
• Simple to undo