Shading is the term given to the process of including dependencies within our JAR at build time, by copying an entire library out of its separate JAR file, renaming packages, and updating code in our application to use the code in the shaded location, rather than at its original location. When our application uses the shaded code, there is no longer any change of diamond dependency conflicts, as it is now effectively an entirely separate codebase that is embedded within your application.
Shading can be an appealing solution to the problem of diamond dependency conflicts, but it does come with its own set of problems. These include:
- When we shade a dependency into our project, we take away our users ability to upgrade the dependency if a concern arises, such as a security vulnerability. This moves the burden back to us to ensure that we are responsive and upgrade to the latest releases for our shaded libraries in as timely manner as possible.
- Shading fundamentally creates new types in new package namespaces that duplicate the existing types. This means that we should not expose these types through any code that we write, if there is a risk that users might