Collecting Framework Dependencies into single Gradle Dependency

To be Reviewed By:

Authors: Udo Kohlmeyer

Status: Draft | Discussion | Active | Dropped | Superseded

Superseded by: N/A

Related: ClassLoader Isolation

Problem

When using frameworks like Spring and Jackson, there is an intrinsic requirement that their usage is linked to a single instance. In the case where multiple modules use the same library, it is highly probable that multiple modules might load the same version of the framework. This usually causes the library to either complain with ClassCastExceptions, as ClassA cannot be cast to ClassA, due to class spanning multiple modules. Another cause would be that the libraries don't perform as intended. An example of this would Spring, where multiple Spring Contexts could be created, all associated to different ClassLoaders, which has the effect that defined beans could be spread across multiple Spring contexts. Which has the effect that beans will not be able to find defined beans. This problem is a little synonymous with Split brain.

In addition to these problems, there is a possibility to increase memory usage due to the loading of the same Class in multiple ClassLoaders.

What is this proposal solving? Why does the problem matter? How does the problem affect the user?

Anti-Goals

What is outside the scope of what the proposal is trying to solve?

Solution

Describe your solution and how it’s going to solve the problem. This is likely the largest section of your proposal and might even include some high-level diagrams if you are proposing code changes. While all important aspects need to be covered, also keep in mind that shorter documents are more likely to be read.

Changes and Additions to Public Interfaces

If you are proposing to add or modify public interfaces, those changes should be outlined here in detail.

Performance Impact

Do you anticipate the proposed changes to impact performance in any way? Are there plans to measure and/or mitigate the impact?

Backwards Compatibility and Upgrade Path

Will the regular rolling upgrade process work with these changes?

How do the proposed changes impact backwards-compatibility? Are message or file formats changing?

Is there a need for a deprecation process to provide an upgrade path to users who will need to adjust their applications?

Prior Art

What would be the alternatives to the proposed solution? What would happen if we don’t solve the problem? Why should this proposal be preferred?

FAQ

Answers to questions you’ve commonly been asked after requesting comments for this proposal.

Errata

What are minor adjustments that had to be made to the proposal since it was approved?