Is there a good comparison between Functional Java and Guava?

Question

I'd like to use either Functional Java or Guava (or less likely Scala) in a course I'll be teaching. Although there are lots of functional languages that run on the JVM I'd like to stick to something that looks as much like Java as possible, i.e., something that will be most compatible, conceptually and syntactically, with the functional features expected in Java 8.

It looks like Functional Java and Guava are the best candidates. I haven't been able to find anything comparing them in terms of capabilities, ease of use, conceptual closeness to straight Java, etc. Does anyone know of a good comparison between these libraries?

Manners

What is the question here? You might want to edit your Q to make it more clear what you're asking... [edit] The Q is in the title, yes, but you may want to rephrase it in the Q itself. – America

Guava is just a Java library with lots of useful utility methods. Yes, it does have some stuff that will allow you to program in a functional-style way, but it is not really especially focussed on functional programming. – Prochronism

Thanks for the answers below. I had mis-understood the goals of Guava. I also spent a bit more time looking at Functional Java. It too is (still) weighed down by current Java syntax. This leads me now to lean toward Scala. I realize that Scala is becoming more and more mainstream. Even so I think it would be most valuable for most students to learn how to do functional programming in straight Java. (When we teach functional programming as a "paradigm" we use Haskell. I doubt that students learn enough, though to get it into their blood.) That leads to the question: when is Java 8 expected? – Manners

Plans for the next version of Java SE 8 are moving forward and Oracle is announcing a revised roadmap for a release with expanded scope, with availability expected in summer 2013. Source: oracle.com/us/corporate/press/512956 – Firth

Just curious: why would you prefer Java over Scala for teaching functional programming? How will the students appreciate the high noise to signal ratio in functional Java? Even in Java you'll have lambdas but still (almost?) none of that category theory level functional stuff that you have in Haskell, Scala, OCaml etc. – Curlpaper

Guava has nothing to do with functional programming. However, there is a library Functional Guava Extensions (fugue) which makes Guava more suitable for functional programming. – Becky

Answer 1

Guava's goal is not to provide functional idioms in Java. From the Functional Explained Guava wiki page:

Excessive use of Guava's functional programming idioms can lead to verbose, confusing, unreadable, and inefficient code. These are by far the most easily (and most commonly) abused parts of Guava, and when you go to preposterous lengths to make your code "a one-liner," the Guava team weeps.

Please be sure, when using Guava's functional utilities, that the traditional imperative way of doing things isn't more readable. Try writing it out. Was that so bad? Was that more readable than the preposterously awkward functional approach you were about to try?

Leaning too heavily on functional idioms makes not too much sense up to Java 7 as the overhead is too high (see vertical problem). This will change with Java 8 which will change the way Java libraries and programs are design on the detail level. Things that make sense in Java up to 7 will be discouraged to some extent in Java 8. This will motivate a new edition of Effective Java and a lot of new APIs.

If you're trying to teach functional programming it's probably better to stick to a (more or less) pure functional language. Every language that is a melange (or emulation) of FP and OOP will be a distraction.

Erdei

I should also point out the preceding sentence in that article: "As of Java 7, functional programming in Java can only be approximated through awkward and verbose use of anonymous classes. This is expected to change in Java 8, but Guava is currently aimed at users of Java 5 and above." – Kush

Answer 2

As stated above, Guava is just a Java library -- a Java 5 compatible library, even (as of release 11). The position of Guava on functional programming is summed up by Kevin Bourrillion:

“The syntax sucks. At the same time, this stuff is now, has always been and will always be nothing but a stopgap measure until the right language change can come along, at which time we can finally really decide on the optimal syntax and have functional-style programming start actually making lives better in Java for once. So I’m undecided how much effort to put into the Function/Predicate stuff; it’s in the library more because it sort of had to be, not so much because we think it’s a crown jewel.”

Kush

Answer 3

Since Guava is more of a general purpose library that happens to have functional idioms, and Functional Java is purely about implementing functional idioms in Java, Functional Java sounds like a better fit with probably a more complete set of FP-like features.

On the flip side, I prefer Guava because it is more general purpose, and therefore I find myself using several of the features that are unrelated to functional idioms.

One of the problems with both libraries (as noted on Guava's Wiki in the above posts) is the "vertical noise" of anonymous inner classes for your functional objects. Another library that attempts to fix this via annotations and the APT is Jedi.

Another approach that makes any of the above libraries (Guava, FJ, or Jedi) less-noisy without annotations is a library that I wrote, Funcito, inspired by the syntax of Mockito. It is more limited in what it can simplify at this point, essentially wrapping single method calls, but that's what I currently find myself doing most of the time already.

Carriole

When you mean vertical noise. Are you talking about the verbose coding as it relates to adding the anonymous inner classes or the overhead in your jar libraries in creating a bunch of those bytecode class files? – Telecast

The former: anonymous inner classes. – Carriole