Java Magazine - November/December 2011

a method, but without all the surrounding class structure.

Java Magazine: Will you give us an overview of some of the most important languages running on the JVM? And how might they be used with Java to improve developer productivity and create more-flexible and robust applications? Buckley: Large systems today succeed based on their technical architecture. That architecture typically has many loosely coupled components, each fulfilling a very specific purpose. Typically, these components collaborate by sharing data in a relational database, or a message bus, or by exposing XML services to each other. The more loosely coupled this architecture, the easier it is to choose the best language for the different components.

User interfaces are generally Web-based and written in HTML or JavaScript, with middleware often written in Java, and back-end logic written in Java, Ruby, or Scala. Groovy is fairly common at build time, and server-side JavaScript is growing in popularity.

A well-designed architecture is clear
about the functional components and
how they interact. Then the appropri-
ate language can be chosen for those
components. Organizations are search-
ing for the right mix of productivity and
maintainability in the languages they
use. Especially on the JVM, components
can be swapped in and out over time.
Sometimes a Java component is rewritten
in Scala, and sometimes a JRuby compo-
nent is rewritten in Java. In many cases,
the same tool suite can be used on the
JVM regardless of the source language.
Java Magazine: Oracle’s upcoming
Nashorn JavaScript interpreter was cov-
ered at the JVM Language Summit. Can
you give us some details?

Buckley: The implementation of lambda expressions (Project Lambda) is a good example. It’s something of a challenge, because the JVM is conceptually streamlined and very focused. The JVM has no knowledge of a lambda expression, a closure, or a continuation. It has no knowledge of type inference or any other language feature that might be designed in support of lambda expressions.

For many years, we could add features to the Java language that mapped directly to JVM features, or in the case of generics, did not show up in the JVM at all. That era of direct mapping is over. With Project Lambda, we needed a way to represent lambda expressions on top of the JVM in a way that is efficient and extensible. In terms of disk space, memory usage, and other overhead, anonymous inner classes were not a reasonable solution.

The invokedynamic instruction provided the solution. It essentially facilitates quick access to method handles. Method handles are really function pointers, and function pointers are a way of manipulating individual blocks of code, which is what lambda expressions are all about. The goal is to give the Java compiler a great deal of flexibility in how to represent these lambda expressions at runtime. That is accomplished by using invokedynamic to set up their creation.

Brian Goetz, From Lambdas to Bytecode

Java Magazine: What are some examples of how lambda expressions could benefit Java developers in a tangible way? Buckley: Lambda expressions are relevant with APIs. The bulk of what developers do involves utilizing someone else’s APIs. A very common task in Java programming is iterating through a collection of business objects, finding ones that match some requirement, and passing that result on to the next step of the program.

Rather than extracting items and writing code to perform those operations (and hoping that nobody else is mutating the collection at the same time), using lambda expressions simplifies things dramatically. If you can pass code, in the form of a lambda expression, to a library, you are basically passing it to the collection itself. Then, concerns such as thread safety become the responsibility of the library implementer, rather than the responsibility of the calling programmer.