[HN Gopher] Guava: Google core libraries for Java
___________________________________________________________________
Guava: Google core libraries for Java
Author : tosh
Score : 38 points
Date : 2023-11-08 20:15 UTC (2 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| bradleyjg wrote:
| 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.
| happymellon wrote:
| Indeed, and now it's just a hassle dealing with Guava CVEs that
| get flagged up for functionality that doesn't actually require
| Guava.
| cosmotic wrote:
| And dealing with mismatching guava versions brought in as
| transitive dependencies.
| mey wrote:
| 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
| erik_seaberg wrote:
| 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!)
| falserum wrote:
| What about just staying with older version, if you don't
| have capacity to upgrade?
| dtech wrote:
| The problem is conflicting transitives, lib A depends on
| 29, B on 31.
| ygra wrote:
| 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?
| mrudolph22 wrote:
| 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.
| aramattamara wrote:
| What about Java modules (aka JEP-200, aka Project Jigsaw,
| completed in 2017)?
|
| Used it for JavaFX apps with no problems.
| ianlevesque wrote:
| 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.
| aramattamara wrote:
| 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).
| macksd wrote:
| That gets tough with transitive dependencies and the
| frequent CVEs.
| vips7L wrote:
| or dealing with the 100 conflicting versions of Guava being
| pulled in as transitive dependencies.
| esafak wrote:
| 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
| nikanj wrote:
| 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
| shrdlu2 wrote:
| That, and also when caffeine came out it replaced one of the
| major uses (caching) of guava.
|
| https://github.com/ben-manes/caffeine
| p1mrx wrote:
| 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.
| rco8786 wrote:
| 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.
| vips7L wrote:
| java.util.Date is kind of bad, but java.time.* is pretty good.
| erik_seaberg wrote:
| It helps that Stephen Colebourne, creator of Joda-Time,
| revisited his own work and designed the new official API.
| vips7L wrote:
| Now I just need to get my coworkers to use Duration instead
| of: long THREE_MINUTES_IN_MILLIS = 3 *
| 60000;
| bad_user wrote:
| At least it has the unit in the name, could be worse.
| kelnos wrote:
| 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.
| The_Colonel wrote:
| java.time is state of the art and has been in Java for 10
| years.
| bad_user wrote:
| Before that, Joda-Time was the de facto standard, with
| `java.time` being a port to the standard library by the same
| author.
| chipgap98 wrote:
| 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.
| cies wrote:
| 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.
| The_Colonel wrote:
| 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).
| renewiltord wrote:
| 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.
| okr wrote:
| With versions later than 21 you shouldn't have the issue with
| breaking changes anymore. Just use latest and dont use @Beta
| annotated classes.
| RedShift1 wrote:
| 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.
| rf15 wrote:
| 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.
| cies wrote:
| 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.
___________________________________________________________________
(page generated 2023-11-08 23:02 UTC)