You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Graph functionality is distributed along with the entire guava
Desired Behavior
To be able to depend on graph module independently
Concrete Use Cases
E.g. our apps uses some corporate bom, which relies on quite old guava verision and it is fine for the common functionality. It is not pretty easy to upgrade guava version in the bom, which used across the company. But we want to leverage the newest graph features as of latest guava artifact. So it would be much more flexible to just pull what we need from graph module without impact on others
Unfortunately, mixing a new version of com.google.common.graph with older versions of other Guava packages will likely lead to runtime errors, since common.graph probably relies on APIs that were added in newer Guava versions.
(There are also some additional problems that would arise if we split Guava after having released it as a full jar for all these years. And even if we'd released it as separate jars all this time, that could lead to issues, too, especially since Maven doesn't resolve version conflicts in favor of the newest version.)
Your best bet is probably to download a new Guava and have a took like Proguard or jarjar rewrite it to a new package, preserving only common.graph and its needed dependencies. (You'd likely also have it "hide" those dependencies by moving them into common.graph as package-private or by giving them an unappealing package name.) Then you could use com.yourcompany.guavagraph.
Also: If there's anything worth sharing about your difficulties with updating Guava, let us know. We know that our past habit of removing APIs was a big cause of problems until ~6 years ago, but we also know that random small problems can break things and force rollbacks. There might well not be much we can do, but let us know if you think otherwise.
API(s)
How do you want it to be improved?
Move it to to a separate module and maven artifact
Why do we need it to be improved?
It will allow to pull the required version of graph functionality into the project independent of the rest of google.guava capabilities.
Example
Current Behavior
Graph functionality is distributed along with the entire guava
Desired Behavior
To be able to depend on graph module independently
Concrete Use Cases
E.g. our apps uses some corporate bom, which relies on quite old guava verision and it is fine for the common functionality. It is not pretty easy to upgrade guava version in the bom, which used across the company. But we want to leverage the newest graph features as of latest guava artifact. So it would be much more flexible to just pull what we need from graph module without impact on others
Checklist
I agree to follow the code of conduct.
I have read and understood the contribution guidelines.
I have read and understood Guava's philosophy, and I strongly believe that this proposal aligns with it.
The text was updated successfully, but these errors were encountered: