-
Notifications
You must be signed in to change notification settings - Fork 6
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
Conversation
There's also CVE-2018-10237 that hits 16.0.1. If this PR is not accepted, would you consider using Guava |
while we wait on java-json-tools/jackson-coreutils#3
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 |
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. |
@soberich If you rebase and squash your change, we can take a look at it isolation. Thanks! |
I will. Can we also backport this to |
There was a problem hiding this 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> | |||
{ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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 JsonPointerException
s serialized in the old system to be deserialized in the new system?
There was a problem hiding this comment.
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.
@Capstan ping. |
There was a problem hiding this 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.
There was a problem hiding this 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> | |||
{ |
There was a problem hiding this comment.
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.
All true. Well, the request was waiting for review and feedback, and as now we are there, we may get to a key question - |
@Capstan this should work now. I prefixed as posted in previous commit. |
b857462
to
dbe3357
Compare
I screwed up CI. Give me a second. |
Ah, no, CI should be fixed as of commit ce6f3a8. Sync and try again? |
@Capstan WDYT? |
@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. |
@Capstan just a ping |
I committed most of this in #42. |
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.