Java 8 will go GA in March 2014. java8_logo The first proposed final draft of Java 8 JSR 337 was released early this week. One of the main components of this JSR is Lambda Expressions for the language (JSR 337). This brings the functional constructs to the language, which will undeniably make Java a top contender among other functional peers (Scala, Groovy, Clojure) on the JVM for Java developers. Conciseness is only part of the story, check out how Java 8 programs start to look with Lambda expressions. While being concise for a casual reader, it clearly makes a case why thinking functional may benefit to Java developers in terms of the powerful constructs it offers. The conciseness does not take away readability of the Java program, instead it makes Java developers feel home and enables functional programming with ease, taking away the heavy lifting usually required for moving away from OO paradigm.

I stole the name “Java.next” from Neal Ford‘s excellent series of articles about functional languages on the JVM. The latest installment of the series was “Java.next: Functional coding styles”. While, the article takes on legacy Java, adding Java 8 to the mix would not hurt. So, let us take his example where you are given a list of names, some of which consist of a single character. You are asked to return the names in a comma-delimited string that contains no single-letter names, with each name capitalized. Here are the various flavors of the implementation taken from the article, while Scala, Groovy and Clojure has its functional version, Java’s implementation is imperative and old school.

Java version:

Scala version:

Groovy version:

Clojure version:

Happy Holidays from the islands

Java 8 version of functional processing

With Java 8, functional interfaces makes this possible with Lambda expressions and Streams make you even more fun when working with Collections in Java 8. Here is the functional version in Java 8.

Switch it to parallelStream() for parallel processing, as simple as that to kick the tires of your cores.

My original intent was to compare with the Java.next languages as perceived by Neal Ford in his article. It is unfair to leave behind some of the cool languages on the JVM. Thanks Luke for bringing this up. I strongly believe top-notch IDE support (Eclipse or Intellij) is a win-win situation for users and language implementors. With that context, I updated my list to include Fantom, Gosu, Xtend, Kotlin, Ceylon in order of their age (oldest first).

Fantom version:

Gosu version

Xtend version:

Kotlin version:

Ceylon version:

Personally, I feel Java 8 and Groovy has better success rate in making developers stay in their comfort zone and still enjoy functional prowess. While, I agree Clojure and Scala versions make their case to different set of developers, I believe maintaining a larger code base will be a challenge, when time to develop and market is ever shrinking, and bringing someone up-to-speed with these language tricks will not be easy. If it looks good, eat it, does not play well when it comes to programming in general. While coming to the newer JVM languages, parallelism is one factor that makes Java 8 easy peasy to deal with. These new breed of languages bring ton of cool features (topic for another blog post!) and attracts developers to the JVM, not just Java developers, which is good for the platform. It remains to be seen in the coming years how well these languages get adopted in mainstream development.

Merry Christmas and Happy New Year everyone!

Update (12/29/2013) : Updated the Java.next languages comparison to include newer JVM languages: Fantom, Gosu, Xtend, Kotlin, Ceylon.

Possibly Related Posts:


The default chunk size in Apache HttpClient 4.3 is set to 2048 bytes. There is no easy way to customize the chunk size in the latest Apache HttpClient release. It looks like the only approach is to implement a custom ClientConnectionFactory that allows to override the default chunk size. Here is an example.

Possibly Related Posts: