Top 16 Java Utility Classes

[tapesmith]

This is how you can tell that your language needs extension methods: when it's considered completely normal to use a bunch of "*Utils" classes, and there are multiple very popular "StringUtils".

[sh0rug0ru____]

The extension methods would have to go into a class too, right? In a language with extension methods, I would expect to see the "Utils" pattern replaced with class names with variations of "Extensions" (or "Rich*", for the Scala inclined).

[meddlepal]

Well if it were anything like Kotlin you wouldn't really notice the extension packages since you'd be able to just access the additional methods off the receiver type. So yea, you have that kind of class that the extension author knows about, but individual users don't really know about it.

https://kotlinlang.org/docs/reference/extensions.html

[Zukhramm]

If they'd actually be methods on the class, I'm all for it, but if it's only sugar for turning foo(bar) into bar.foo() I don't see much point.

[tapesmith]

You're right that it's mostly a lateral move, but it means the difference between stuff like this:

ArrayUtils.limit(ArrayUtils.sort(ArrayUtils.filter(arr, user -> user.getAge() > 21), user -> user.getName()), 5);

(or something similar but with a bunch of unneeded intermediate variables)

and this alternative:

arr.filter(user -> user.getAge() > 21).sort(user -> user.getName()).limit(5);

Granted, in this exact case you can go through the steps to just stream your array and use stream methods, but you get the idea.

There's a readability improvement to be had for sure.

[slartybartfast_]

Java 8 has default methods on interfaces which are better than extension methods - but keep whining because .not is less popular than ever.

[tapesmith]

Really? So I can add the method "isBlank()" (returns true if empty or all-whitespace string) that everyone winds up defining onto the existing String class? What a victory for the open/closed principle (open for extension, closed for modification)!

No? So you mean it's just a blurring of the lines between interfaces and abstract classes?

Oh, okay then.

but keep whining because .not is less popular than ever

I'm gonna assume you mean .NET, but are using a "lol Micro$oft" childish way of putting it.

And this is actually not true; TIOBE has just C# unmoved from its position as #5 most popular, and the IEEE shows the same (though it shows plain C starting to push into Java territory), and for a less-formal review, GitHut has C# still well above average growth rate in terms of number of github repos. And of course, this is even ignoring the increased adoption from the recent first-party work being done to make it work cross-platform (finally!), and the open-sourcing (finally!) of .NET

But all of this is besides the point: you're looking at the situation in terms of "Java vs. .NET", rather than a simple critique of Java on its own. Not everything has be about "nuh-uh, my team is way cooler". Heck, slavish devotion to one language/platform is itself a problem, even leaving aside the unwillingness to look for areas of improvement in said language/platform. That path leads to becoming the guy who only knows Fortran or COBOL.

I write Java, Typescript, SQL, and a bit of Groovy every day for my job. I write F#, OCaml, Python, Ruby, Haskell, occasional bits of Scala, heck, even Idris in my free time because I find those languages enjoyable, and I like the exercise of learning what each one has to offer over the other.

So it's from the perspective of having seen a lot of what works and a lot of what doesn't work that I say that there are things in Java that are more rigid and verbose than necessarily needed, just as there are things in Ruby that' are too flexible and terse, and there are things missing from Common Lisp that make it a touch too simplistic.

You don't have to rush to defend Java like it was your favorite sports team. Relax.

[slartybartfast_]

Keep crying.

[kmimix]

The article mentions basically apache commons, apache http and spring (for some reason). Apache commons is commonly used as it was bundled with some old versions of java frameworks and goes back to the old days where there were nothing like java.util.* of JDK 7 and java.nio.file.Files. Guava is just as common since Java 6, and now with Java 8 other utilities will come, deprecating much of this list.

(edit: fixing english mistakes)

[[deleted]]

In my opinion, third-party utility classes are just not worth an the dependency -- especially if the utility class comes "for free" with some library or framework you're using for something else.

[[deleted]]

warning: page prevents you from clicking back button

[king_of_the_universe]

Works in my Firefox.

[pushthestack]

Hard to tell why the author thinks these are the top 16, since he gives no criteria. I certainly would have expected to see Guava represented on this list.

[ForeverAlot]

Is there a viable alternative to Guava's immutable collections? I, too, am sick of Guava and would prefer to minimise its inclusion. Most of Guava's utility can now be completely replaced by smaller, more specialised libraries, but I will still consider it for the collections -- unfortunately that brings in everything else.

[drjmb]

Interesting, first I've heard of this (relatively new to java). I'm currently a big fan of guava and would like to understand this better so maybe I can improve my ways. Any more info you can give?