Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removed Guava, bump Gradle and all deps. #3

Closed
wants to merge 2 commits into from

Conversation

soberich
Copy link

Hi,
We really want to remove Guava as it is on of the largest deps in war though required by this dependency (and json-patch). This would ease the choice to depend or not on Guava.
Please kindly review.
No "optimizations" made. Just a plain migration with practically coping and pasting logic from Guava's methods (Guava is a great library but we just have a JAX-RS web-app and Guava is a too big contributor to classpath).

Overview.

Removed Guava
Bump gradlew to 5.0 and adjust scripts for compatibility
Builds and tests run now on Java 6-11
Bump all versions to top available.

@ar
Copy link

ar commented Mar 12, 2019

There's also CVE-2018-10237 that hits 16.0.1.

If this PR is not accepted, would you consider using Guava 27.1-jre instead of 16.0.1 ?

ar added a commit to jpos/jPOS-EE that referenced this pull request Mar 13, 2019
@Capstan
Copy link

Capstan commented Aug 30, 2019

I am starting to look at CVEs in this and its dependents. I want to sever the Gradle changes from the Guava changes, so I'll probably crib from this to get it building, commit, and then evaluate code changes separately. /cc @huggsboson

@Capstan Capstan mentioned this pull request Aug 30, 2019
@Capstan
Copy link

Capstan commented Aug 30, 2019

Guava has been updated in pr #8 so the Guava removal can be considered on its own. /cc @ar

@soberich
Copy link
Author

soberich commented Aug 30, 2019

@Capstan Guys, wait. What is the reason to leave Guava? Again, let's remove it. It is not needed. I see this as simply much better approach. Why do half-action when we should go full. @Capstan Why making PR #8?

@Capstan
Copy link

Capstan commented Aug 30, 2019

Bumping the version was, IMO, the safest, quickest way to mitigate the CVE that @ar mentioned. It is not meant to represent a final decision on the "whether Guava" front.

@Capstan
Copy link

Capstan commented Aug 30, 2019

@soberich If you rebase and squash your change, we can take a look at it isolation. Thanks!

@soberich
Copy link
Author

soberich commented Aug 30, 2019

I will. Can we also backport this to fge coordinates afterwords? This woul be really really in demand I believe.

Copy link

@Capstan Capstan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, this seems like a fairly reasonable change to reduce the weight of this library without making it unduly complex. I'd like to ensure that it's backwards compatible or that we're happy making another major version bump before we take it.

My knowledge of OSGi is near zilch, and I'm not sure if there are other implications I'm not considering.

/cc @huggsboson

@@ -41,21 +41,50 @@
* kind of equality.</p>
*/
public final class JsonNumEquals
extends Equivalence<JsonNode>
{
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing this extension seems like a breaking change.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why?
Do you believe anyone relies in it in hierarchy while working with JsonNumEquals?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't believe anything either way. I do know I cannot survey all users of the library. I do know it's part of the surface, and any user could have legitimately started relying on it. By semver conventions, that implies removing it is a breaking change and would necessitate a major version bump.

I'm also not averse to major version bumps for such changes, but I'm apparently an outlier, as others want the major version to be more associated with a collection of features than with API compat. As the new kid on this block, I'm going to defer to the more senior maintainers, if they express a preference.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me start looking at it. I will today/tomorrow.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No rush. Just to expectation set, as soon as I have permissions, I'm going to cut a 1.10 release with just the dependency version bumps. If this commit is accepted, it'll be in a following release.

Copy link
Author

@soberich soberich Sep 3, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Capstan I am confused a bit. But I didn't remove that I shaded it. Which changes were you looking at? Basically it was all good and you consern already was resolved originally. I will squash it.

Copy link

@Capstan Capstan Oct 18, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure what "shaded" means in this context. Removing the extends Equivalence<JsonNode> removes the Equivalents parentage, which is absolutely necessary if we're removing Guava references. The remaining question is do we bump the major version for this change or not.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also probably need to make sure that at least the dependent projects in the java-json-tools don't rely on this. Not sure exactly best way to do that without using snapshot releases.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity, what other java-json-tools modules do you want to de-Guava to re: issue #11 ? What gets pulled into your JAX-RS app today?

I ask because while this removal is totally feasible, if you're including other libraries for which it is less feasible, this might not be worth finishing.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, now I'm seeing your re-add of Equivalence. And now I understand "shading" to mean "shadowing", and no, I'm not excited to fork parts of Guava into this project. Either we should remove references to it outright, or keep the Guava references, but having this will cause code collisions for the people who include this and Guava.

@@ -22,6 +22,8 @@
public final class JsonPointerException
extends Exception
{
static final long serialVersionUID = -1835450876546372005L;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity, where did this come from? Does this allow JsonPointerExceptions serialized in the old system to be deserialized in the new system?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was long ago, but I think it was just a quick refactor for Sonar satisfaction.

@soberich
Copy link
Author

@Capstan
I have rebased.
I have seen this #11, but I don't see Guava now in a dependency tree of my fork (this PR). Maybe I didn't get what you mean there.
Anyway now we have a green bar here to proceed.
Thanks.

@soberich
Copy link
Author

@Capstan ping.

Copy link

@Capstan Capstan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks good. I have a couple outstanding questions around Equivalence and change scope beyond this library.

Copy link

@Capstan Capstan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove the shadow copy of Guava's Equivalence (i.e., drop commit 9700917).

@@ -41,21 +41,50 @@
* kind of equality.</p>
*/
public final class JsonNumEquals
extends Equivalence<JsonNode>
{
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, now I'm seeing your re-add of Equivalence. And now I understand "shading" to mean "shadowing", and no, I'm not excited to fork parts of Guava into this project. Either we should remove references to it outright, or keep the Guava references, but having this will cause code collisions for the people who include this and Guava.

@soberich
Copy link
Author

All true. Well, the request was waiting for review and feedback, and as now we are there, we may get to a key question -
Are going to bump the (major) version or not?Because if yes, I will simply properly shadow those classes by prefixing "com.google..." package name with library name-space.
Initially PR was "for discussion" in my mind on this matter, as if maybe we would want to somehow keep the version.
@Capstan about your previous comment. If we will bump the version I will change package. This should be a solution. Right?

@soberich
Copy link
Author

soberich commented Nov 2, 2019

@Capstan this should work now. I prefixed as posted in previous commit.
I can squash all after you review if needed.

@soberich soberich force-pushed the master branch 3 times, most recently from b857462 to dbe3357 Compare November 2, 2019 16:50
@Capstan
Copy link

Capstan commented Nov 5, 2019

I screwed up CI. Give me a second.

@Capstan
Copy link

Capstan commented Nov 5, 2019

Ah, no, CI should be fixed as of commit ce6f3a8. Sync and try again?

@soberich
Copy link
Author

soberich commented Dec 7, 2019

@Capstan WDYT?

@soberich
Copy link
Author

soberich commented Dec 7, 2019

@Capstan I rebased it multiple times, so now you probably proceed with some javadoc linting and javadoc fails. Can we finish the work and merge. You can make minor changes youself such as javadoc, I it is hard to follow those minors and rebasing everytime. The PR intention is to remove Guava which is done. Let's do it then. Again feel free to make any adjustments.

@soberich
Copy link
Author

@Capstan just a ping

@Capstan
Copy link

Capstan commented Jan 6, 2020

I committed most of this in #42.

@Capstan Capstan closed this Jan 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants