Classpath override with Gradle

I’m using Gradle in one of my Java projects. One of the third party libraries that I’m using in the code has a known bug that will be fixed in the next release. While there is no release I would like to fix it locally. Usually when I wanted to do this in a Maven-based project, I would use classpath override for the buggy 3rd-party class, fix it in my code and then remove this “hack” after the fixed version is release.

For some reason, I’m not able to do this (at least the way I usually did) when running Gradle tasks. Does Gradle use a different classpath order to run the Groovy code and that disables this “feature”?

Does anyone already faced this problem before? Is it possible to do this? How?

1 Like

Can you please elaborate on the “way you tried it”? What “feature” are you referring to?

Classpath override is a hack used to usually replace a class implementation present in a third party jar. By creating a class in your code base with the same canonical name (package + class name) as the 3rd party class you want to replace and setting the classpath in the right order, you are able to trick the class loader into ignoring the 3rd party implementation of that class and using the one you provide.

Here is a typical situation:

1 Like

So where exactly in your build are you re-defining the class?

In my project’s src/main/java/[package-dir-structure] directory. The class to be replaced is in an external dependency (jar).