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 clearabout the functional components andhow they interact. Then the appropri-ate language can be chosen for thosecomponents. Organizations are search-ing for the right mix of productivity andmaintainability in the languages theyuse. Especially on the JVM, componentscan be swapped in and out over time.Sometimes a Java component is rewrittenin Scala, and sometimes a JRuby compo-nent is rewritten in Java. In many cases,the same tool suite can be used on theJVM regardless of the source language.Java Magazine: Oracle’s upcomingNashorn JavaScript interpreter was cov-ered at the JVM Language Summit. Canyou 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.