Guava: Google core libraries for Java(github.com)
github.com
Guava: Google core libraries for Java
https://github.com/google/guava
50 comments
This used to be much more valuable in older versions of java. But some of the most useful parts now have analogues in the standard library.
That, and also when caffeine came out it replaced one of the major uses (caching) of guava.
https://github.com/ben-manes/caffeine
https://github.com/ben-manes/caffeine
Yeah this was about the last piece I’d really go to Guava for and Caffeine has been better for years at this point.
Indeed, and now it's just a hassle dealing with Guava CVEs that get flagged up for functionality that doesn't actually require Guava.
And dealing with mismatching guava versions brought in as transitive dependencies.
I wish Guava weren’t just one library that breaks backward compatibility casually. They follow semver, but the major version changes so often that it’s not that helpful (they’re up to 32.x!)
What about just staying with older version, if you don’t have capacity to upgrade?
That gets tough with transitive dependencies and the frequent CVEs.
The problem is conflicting transitives, lib A depends on 29, B on 31.
[deleted]
Does Java have a solution for such things where both libs can use their own version without them conflicting (unless they hand out Guava types to others, of course)? Custom class loaders?
In some cases, shading can also help. That, basically, renames a classes used in a jar. It has to be done by the creator of the jar, though.
https://stackoverflow.com/a/49811665:
“If your uber JAR is likely to be used as a dependency in another application then there's a risk that the versions of the dependent classes in the uber JAR might clash with versions of those same dependencies in this other application. Shading helps to avoid any such issue by renaming the packages within the uber JAR”
> unless they hand out Guava types to others, of course
You still can hand out guava objects to others, as long as you hand them out as being of a standard Java interface.
That will work as long as the receiver of the type uses instanceof with a class type or reflection, so it is a bit brittle. Technically, any breakage would indicate a bug in the receiving code, but fixing it cleanly may be impossible.
https://stackoverflow.com/a/49811665:
“If your uber JAR is likely to be used as a dependency in another application then there's a risk that the versions of the dependent classes in the uber JAR might clash with versions of those same dependencies in this other application. Shading helps to avoid any such issue by renaming the packages within the uber JAR”
> unless they hand out Guava types to others, of course
You still can hand out guava objects to others, as long as you hand them out as being of a standard Java interface.
That will work as long as the receiver of the type uses instanceof with a class type or reflection, so it is a bit brittle. Technically, any breakage would indicate a bug in the receiving code, but fixing it cleanly may be impossible.
Java doesn’t have a universal practical solution for this. Principled solutions based on custom class loaders (such as OSGi) added tremendous complexity and created more problems than they solved. Other solutions such as shading (renaming classes and their usages to prevent name conflicts between different versions) work in some cases but have their own limitations and drawbacks.
What about Java modules (aka JEP-200, aka Project Jigsaw, completed in 2017)?
Used it for JavaFX apps with no problems.
Used it for JavaFX apps with no problems.
Java modules are fine but don’t offer a solution for version conflicts.
Yes custom class loaders can solve this. Eclipse had an entire OSGI module system that did this among other things. In general though Java (and Kotlin) have been trending toward simpler and lighter though for years and I’d recommend just sorting out your dependencies, even drop some, to avoid that kind of thing.
Yes, it's called Java modules (aka JEP-200).
Although people often skip it and put everything in one module. It was released in Java 9 (started in 2014 and completed fully in 2017).
Although people often skip it and put everything in one module. It was released in Java 9 (started in 2014 and completed fully in 2017).
AFAIK Jigsaw solves a different problem. The transitive dep will still be found on the module path.
AKA "diamond dependencies"
Java 9 modules address this.
Java 9 modules address this.
> What about just staying with older version
See grandparent: "dealing with mismatching guava versions brought in as transitive dependencies"
See grandparent: "dealing with mismatching guava versions brought in as transitive dependencies"
Even better is getting Gradle/Maven to correctly pull "plain" vs "Android" versions of the package instead of them just publishing the diverging code base as two repository packages.
https://github.com/google/guava/issues/2914
https://github.com/google/guava/issues/2914
CVEs are terrible nowadays. Any enterprising ”security researcher” can file one against your project, and the CVE aggregators will flat refuse to take it down. See for example CVE-2023-29827 or CVE-2023-35116
Unfortunately that doesn't prevent "security" from putting checks in the build pipelines.
or dealing with the 100 conflicting versions of Guava being pulled in as transitive dependencies.
I dealt with a repo that admitted only one version of each library, probably following Google's lead, so we were stuck with an old version of Guava because it was used all over the place, and upgrading it would have required a lot of refactoring which was not worth anyone's time. One reason to prefer smaller libraries. https://en.wikipedia.org/wiki/Public_goods_game
Does the standard library have a function to parse IP addresses without querying DNS? InetAddresses.forString() was the main reason I used Guava in the past.
InetAddress::getByName
This queries dns in some cases
One of the newer things I've appreciated from guava is ListenableFuture to Kotlin suspend functions interop.
This and Apache Commons is the jQuery of Java - once a useful tool to get cutting edge features and entire paradigms into older versions, now a security risk and surprisingly unperformant compared to what the standard library has to offer.
I think we were able to remove 99% of usage of Guava and Apache Commons Lang/Text by porting the remainder of our code over to Kotlin. Kotlin's stdlib has most of what we used from these tool libs built-in. The remaining 1% + removing the deps is on the backlog.
We may at some point go with Kotlin's Arrow lib (an FP specific tool lib), which may be akin to underscore.js in JS.
We may at some point go with Kotlin's Arrow lib (an FP specific tool lib), which may be akin to underscore.js in JS.
Happy Guava user here. I frequently use the services and eventbus bits. Some of the io, primitives and cache stuff. Table is also useful. Very nice to have this, has definitely made life easier for me.
From the documentation... "We recommend against using EventBus. It was designed many years ago, and newer libraries offer better ways to decouple components and react to events."
I am yet to find somethinf as simple and effective as EventBus. I'm just gonna keep using it as long as it's in the library.
I liked Apache Commons collections for major versioning their releases. Collections 4 is in the collections4 package. Allows having both versions and incrementally migrating. Would have been useful because Guava is like JQuery: it had so much useful stuff, upstream stuff would often include it and then you have to worry about compatibility.
With versions later than 21 you shouldn't have the issue with breaking changes anymore. Just use latest and dont use @Beta annotated classes.
Not 100% sure why this is here, considering its age, but it always struck me as strange that they never did anything with Dates. The stdlib offering for Dates in Java/JVM environments is atrocious.
Not sure what you mean. java.util.Date is terrible, but the newer java.util.time.* classes are some of the best I've worked with when it comes to datetimes.
java.time is state of the art and has been in Java for 10 years.
Before that, Joda-Time was the de facto standard, with `java.time` being a port to the standard library by the same author.
This makes it sound like joda and java.time are the same. They have major differences and java.time fixes a lot of the problems with joda time.
I use both (Joda in a legacy code base) and the similarity is clear (as the other user pointed out, both designed by the same author).
They are in part by the same author. And so is the threeten library that extend the java8 time lib with some useful-but-edgecasey additions.
java.util.Date is kind of bad, but java.time.* is pretty good.
It helps that Stephen Colebourne, creator of Joda-Time, revisited his own work and designed the new official API.
Joda time already did that.
(And then it was included in Java 8 in java.time.*)
(And then it was included in Java 8 in java.time.*)