I am a fan of Guava, not just as a very useful library, but as a way to read really good Java code. Check the source out, it is imo a must if you are a java dev.
One thing I'm not a fan of is the functional stuff. The idea is good, but java is just too verbose. Without real lambdas, like C# has now, it ends up being not so useful.
I'm a big fan of the functional stuff. Writing transform statements using for loops is painful and error prone in comparison to a quick anonymous function using Collections2. Yes, it looks ugly, but at least there's less duplication, and if you're using code completion in an IDE (which you are, because it's java), it's actually faster to write.
The whole Java is too verbose argument is starting to sound like a broken record. With an IDE and tools like ProjectLombok around, you don't need to type much more than most other languages. I code a lot in CoffeeScript and Java and I type less in Java because at least it has static types and code completion. Try renaming a method or variable in CoffeeScript. ;-) ctrl-space (code completion) and annotations are your friends. Obviously Java8 makes the whole argument go away and now that the multi-year stalemate on Java7 is over, we know that Sunacle is focused on getting Java8 out as well.
This whole "with IDEs, you don't need to type that much" argument is starting to sound like a broken record. First off, it's good you don't need to type that much with modern IDEs because they all suck at keeping up with a programmer typing at a decent clip.
As others have pointed out, it's not about how much typing you need to do. It's about how quickly you can form, in your head, a conceptual model of what you see on screen and how accurate that model is. While dog-slow IDEs, half-assed Java-style static typing, etc may help you with that, Java's verbosity certainly does not.
Agreed. I spend way more time in the debugger in CoffeeScript than I do with Java, simply because I have no idea what type of object I'm dealing with at that particular instant. I also tend to write pages of Java code and it runs the first time because I can read it and see exactly what it is doing before it runs. The compiler also tells me what typos I have in my code before I even have to run it.
I don't buy this for a second for many reasons. First, in Java I have to deal with a lot of other headaches. Heaven forbid I have to customize maven! Or, I'm using some annotation based framework, let's say jax-rs, and I'm trying to figure out why the annotations I'm putting on something aren't having the effect I think they should be having. Then there is the fact that my java project will likely have more lines of xml than lines of code in the equivalent ruby project.
But, at the end of the day I'll bet money that I can write a non trivial website faster with rails using notepad than the vast majority of java people can with their favorite IDE and java framework.
Sorry, I wrote more than one comment in this thread and was referring to one of the others. Java is much more verbose and I believe that has a negative impact. Here's the example I used earlier: http://jaydonnell.com/blog/2011/08/07/is-your-idea-clearly-e...
That same code in C# would be nearly as concise as the ruby code. But there is more to it than just this. I've seen large Java projects that can't decide if they want to use interfaces or abstract classes. I don't think this is something one should spend much time on, but you're forced to in Java.
I've also see large java projects where they have some public interface that a bunch of other people are building off of, and after a couple years they realize they need to add a method to it. Ruh roh, what now? Again, why is this so painful?
Obviously these aren't problems in ruby because you can change classes at will. This scares some people, but I've done a LOT Of ruby and haven't had any serious problems with it. If you really like static typing then scala solves these problems as well and keeps the static typing.
Oh, another problem I've had in java are two frameworks butting heads over which is in the drivers seat as far as annotation based dispatch. Look back at the early days of combining guice with jax-rs.
I just wrote a 300 line Java class to replace a 30 line Python script, so I don't think the criticism is unwarranted. (Python is not an official production language. And no, it's not a hidebound corp. Proposed changes need proof)
> The whole Java is too verbose argument is starting to sound like a broken record. With an IDE and tools like ProjectLombok around, you don't need to type much more than most other languages.
The fact that you need an IDE to handle all the boilerplate for you should indicate the language is too verbose. In fact I feel like that's what it means for a language to be too verbose.
That is like saying a carpenter doesn't need a hammer. An IDE is just a tool for doing your job. You don't actually need an IDE to write Java, but it sure makes it a lot easier to build a house.
Correct. You don't actually need an IDE to write Java but unless you have one you're going to be writing a lot of boilerplate by hand. That is the point I am making. The language is verbose whether or not you have an IDE. The IDE simply helps you manage that verbosity.
It's instructive for all programmers (not just Java) because it's a beautifully designed API.
It's really difficult to design a good API and Guava didn't get to be like this overnight. It was used internally at google for years then spent years as a pre-1.0 open source project.
Check out GWT code too, similar writing and design style.
On thr other hand, I always have to pause and think a littlr bit longer when using the Guava PreConditions.checkArgument call (even the author of Guava admitted that too)
I don't follow Java development, but I have worked in it occasionally, and every time I do something in it, I'm inevitably surprised by having to use one of this commons libraries for something basic.
Is there a reason some of this stuff isn't added to the base framework?
- Java has historically included things in its standard library that (presumably) everyone regrets nowadays, like CORBA support. The standard JRE is already overweight. Also keep in mind that size matters for Java - in theory, it's a client side environment that's downloaded and installed by consumers (of course, in practice nobody does that anymore).
- The standard library has to be implemented by all JVM vendors, so adding lots of stuff to it that can also easily be shipped as a library creates a lot of unnecessary effort.
- Changes to the Java standard library have to go through a committee process (JCP); again, it's probably just not worth the effort.
Bear in mind the in-progress modularity JSR (http://jcp.org/en/jsr/detail?id=294) that might help this problem. Also, some people won't want everything that Guava provides.
The important algorithms are in the core library. This is a more friendly API to use both collections and operations on them. And while I love what Guava brings to the table, I do not agree with bringing API candy into base Java. When it comes to heavily used things like collections, this is obviously a gray area. My preference is that they obsolete the need for several of these things at the grammar-level with list/map syntax and [real] closures.
A lot of the most useful stuff in Guava is coming in JDK8 - most of the collection/functional APIs. Still, I'm surprised by your observation. What are you coming from that has a more comprehensive standard library? All I can think of is possibly .NET.
Sadly not in maven repo yet so my company can't use it. I have played around some with functional java (functionaljava.org) and Op4j. Have you compared bolts to either of those?
As far as I know, functional java was used as inspiration, but bolts were much more suitable for day to day tasks (a lot of pragmatic code already there).
No idea about the recent development in fj, they probably made some improvements in the meantime, too.
If I were writing the code to use, I would do exactly that. Since it was a explanatory tutorial, I wanted people to see what was happening. Later on I've used static imports after explaining what classes they need to look at for the code. I totally understand your point of view though.
Java 6 source was introduced without explicit intention and once detected was not addressed. Many companies would not use something whose vital dependencies change on a whim or oversight. A lot of shops are still using Java 5 compilers and have no immediate plan to upgrade. Some cannot upgrade conveniently.
Your comment might be misunderstood. While Guava now requires Java 6 to compile, it is not required to run it. Guava is still targeting Java 5. You can use it by declaring a Maven dependency or by adding the latest Guava jar to your project libraries... But yeah, it forces you to upgrade your compiler.
Kevin Bourrillion (Guava lead developer) just made an insightful reply on this subject in the issue tracker:
> Saw this bug referenced as "a reason not to use Guava."
> Does everyone understand that Guava is still perfectly
> *usable* on JDK 5, it just can't be *built* using JDK 5,
> and that part of the reason for that is *compiler bugs*
> in JDK 5 whose fixes in 6 were never backported?
We've started using Guava recently and one of my favorite changes is that you no longer need try/catches around string conversions in case the OS doesn't support utf-8.
Yes. Passing Charset arguments as String not only forces you to deal with the checked UnsupportedEncodingException, but it's also brittle: it's easy to make a typo (is it "utf8", "utf-8", "UTF8", or "UTF-8"?) and get a runtime failure.
I don't really see what this has to do with the article itself. It's totally ridiculous to compare learning a new language, developer tools etc. with adding a single library to a project. Also, Scala is specifically designed to bring many benefits at the language and library level that Guava won't.
I really find this kind of Snark disappointing on HN, and one of the many examples of a decline in the quality of comments that PG has talked about.
Sorry to have been so prompt. What I meant was "if you want more than that, I would recommand Scala".
Scala is close to Java because it compiles to JVM and you can use Java libraries in scala (so that's not a big deal to switch to it).
You can nearly code in scala like in Java with some syntax improvment and in a functional way.
I agree with him - what Guava brings (functional programming, better safety in types) is something that is better done at language level like in Scala.
Either you like Java and you don't need Guava, or you want functional programming and other goodness and for that Scala is a better language.
I'd have to agree. One of the main benefits touted for guava in this article is the ability to use java libs with cleaner syntax. Scala already enables us to do that, and a lot more. I've coded java for the last 12 years, but have to admit there's no denying that there are cleaner ways of getting things done in Scala, Ruby, Python etc. of those 3 scala is the only one fast enough to be taken seriously.
One thing I'm not a fan of is the functional stuff. The idea is good, but java is just too verbose. Without real lambdas, like C# has now, it ends up being not so useful.