Remove Guava dependency

[lordofthejars]

I know that it could imply a bit of work, but currently we would discard using this library because of Guava dependency. Not because we have nothing against Guava (in fact it is a really good library), but because we don't want to get a 2MB library when in fact only 2% of the whole library is being used. IMHO no general library should use so big dependencies.

[fge]

Sorry, but I do intend to keep depending on Guava. And it is not json-patch itself which depends on it, but jackson-coreutils (for JSON numeric equivalence, required by RFC 6902, and some other things). I also use it for the Sets class, Preconditions etc. If anything, the code will evolve to depend more on Guava.

Also, I know there are people like you and others who keep arguing about "size vs actual use", but in 2014 I believe the point is moot; 2 MiB is nothing. In fact, I was one to argue about this but eventually realized that this is, ultimately, a non problem.

[lordofthejars]

hi well the problem is the space in minor cases but also that we are not pretty sure to use guava in our classpath for company's philosophy because we have another approach for utilities class. The question is, would you accept a PR removing Guava and implementing the same but using self classes? We have time to contribute in the project because we are really interested in it.

Thanks.

[fge]

Well, if you can spare the time it's fine, I guess...

This will mean you will have to get rid of the jackson-coreutils dependency (but not its dependencies) and program an equivalence to JsonNumEquals (that will be the delicate part), get rid of all Sets.*() calls, get rid of all Preconditions (this will take some time too); also, for tests, when reading JSON, you will have to get rid of all calls to JacksonUtils.get*() and JsonLoader.*() and create ObjectMappers manually instead. Ensure that the mapper uses USE_BIGDECIMAL_FOR_FLOATS! Otherwise Jackson will limit itself to doubles for floating point values.

In order, that would be:

• replace calls to JacksonUtils.get*() and JsonLoader.*() with ObjectMappers;
• implement an equivalence to JsonNumEquals (since this project doesn't use collections with wrapped JsonNodes you can limit yourself to equality), replace all calls to it;
• replace all calls to Sets.*(), Lists.*();
• replace all calls to Preconditions (that will be very long; there are a lot of them);
• "inline" all of jackson-coreutils dependencies except for guava.

That should do it...

[fge]

Uh, no, I retract; that won't do it! You need JsonPointer too...

Note that jackson 2.4.x has support for it; however I don't fully trust it whereas I fully trust my implementation.

[daveclayton]

Perhaps we could consider this as part of work to split out the API as per discussion in issue #22

What do people think?

[Capstan]

Fixed in #66.

[asoldano]

@Capstan what are the plans wrt releasing a new version of json-patch (and required dep updates) including this guava removal? Any ETA?

[Capstan]

Since it eats about a workday to go through all these, I was planning to do another set of java-json-tools releases early Q2.

[asoldano]

I see, thanks, so that means 2-3 months from now I guess. Looking forward to that for inclusion in RESTEasy.