Today, Oracle rolled out Java 8, which for all Java programmers  regardless of their occupations and interests  is a major event. The release is unarguably the most important version since Java 2 last century and, as I'll explore shortly, possibly more important than that release, which assured the prominent place the language and platform have enjoyed ever since.

What makes Java 8 so compelling is its embrace of the functional programming metaphor. This embrace has two primary expressions: the use of closures (or as Java calls them, "lambdas") and the adoption of composition as a central approach to development. Lambdas, while not quite full first-class functions, enable passing code as a parameter to a function, within limited contexts. By limited, I mean only the mechanics of it, not the opportunities to do so. As Brian Goetz of Oracle explains, once the syntax of lambdas had been finalized and its implementation completed, the Java team found numerous opportunities to use lambdas to streamline the standard libraries. They discovered that not only was the code clearer, but the performance better. Implicit is that latent defects were removed, too, as code size was reduced.

The new streams feature in Java 8 enables composability. This language trait, recently explained by Walter Bright, enables software to be implemented using a model that operates like this: data source → algorithm → data sink. This model is highly desirable on today's platforms where such computational streams can be run in parallel and thereby make full use of multicore processors. It is also an excellent fit in processing Big Data.

Purists will argue that these two changes, even when taken together, don't make Java a functional language. They're correct, but that was hardly the goal. The idea, which looks like it's been achieved elegantly, is to give OO developers functional capabilities in ways that are immediately usable and useful, without imposing a significant learning curve or rewiring of the way they've previously written code.

Other new features include the ability to add defined default methods to interfaces and to define static methods in interfaces  both of which will save a lot of code and make interfaces considerably more useful.

The libraries contain many upgrades: improved I/O and NIO, parallel options for arrays and other collections, a completely revamped Date and Time library, and so forth.

Finally, there is the complete replacement of the former Rhino JavaScript engine with Nashorn. Since Java 6, the JVM has enabled scripting engines to be called by Java programs. The default language has been JavaScript, although others (such as Groovy) exist. The engines enable developers to give their users the ability to configure and program their software package, in much the same way Tcl did and Lua does for C programs. The problem was that Rhino was slow. Nashorn is a faster rewrite whose generated code is JITed, meaning that it is now possible for developers to write larger parts of their original Java program in JavaScript, without suffering a performance penalty. And, likewise, their users will see considerably better performance for the extensions they write.

The only major feature that did not make it on board the Java 8 train was Project Jigsaw, which would allow smaller Java binaries to be shipped with an application by introducing profiles. However, this feature has been promised for the next major release.

It is tempting to argue that many of these benefits previously existed in other JVM languages, such as Groovy and Scala. This is largely true. Their adoption by Oracle shows a welcome appreciation of technology not originally developed by the company itself. But to be clear, by adding them to Java, Oracle has improved the features by eliminating the side-effects of those languages, such as Groovy's lesser performance or Scala's lengthy compilation cycles.

I've already downloaded the Java 8 bits and begun using the new features. The more I do so, the more impressed I am by how much Oracle has included in this release. In terms of fundamental changes, there are few counterparts to upgrades of so large a scope to a language in such wide and active use.

I think this release is so important that quick adoption will deliver important benefits right away. It would not surprise me if we soon look back at pre-Java 8 code as a kind of legacy artifact in the same way we view pre-ANSI C.

 Andrew Binstock

Editor in Chief

[email protected]

Twitter: platypusguy

Google+