| By Janice J. Heiss |
|
| We caught up with Oracle’s Java Language Architect, Brian Goetz, to get his thoughts on concurrency, Java SE 7 and 8, developments in the Java Virtual Machine (JVM), and more. |
|
|
|
Few people have thought as long and hard about the Java platform
as Oracle’s Java Language Architect, Brian Goetz. He has published more
than 80 articles on such topics as best practices, platform internals,
and concurrent programming, and he is the principal author of Java Concurrency in Practice,
a 2006 Jolt Award Finalist and the best-selling book at the 2006
JavaOne conference. Prior to joining Sun Microsystems in August of 2006,
he was a software consultant who, in addition to writing about Java
technology, spoke frequently at conferences and gave presentations on
threading, the Java programming language memory model, garbage
collection, Java technology performance myths, and other topics.
At Sun from 2006-2010, Brian worked on a number of projects,
including being architect for the JavaFX Script compiler and architect
for the Java Warehouse. After arriving at Oracle, he was given the
title of Java Language Architect. He is a leader of Project Lambda,
an element of Java Platform, Standard Edition (Java SE) 8 that will
provide closures and related language features for the Java language, as
well as upgrades to the core Java libraries to more easily express
parallel calculations on collections. Lambda also includes the addition
of virtual extension methods, which address the long-standing problem
that once an interface is defined, developers cannot add new methods to
it without breaking existing implementations.
We met with him to get his thoughts on concurrency, Java SE 7 and
8, developments in the Java Virtual Machine (JVM), and other matters.
Q: In a March 2007 interview
you made a statement that I’ve quoted to many leading Java developers:
“Often, the way to write fast code in Java applications is to write dumb
code -- code that is straightforward, clean, and follows the most
obvious object-oriented principles. This has to do with the nature of
dynamic compilers, which are big pattern-matching engines. Because
compilers are written by humans who have schedules and time budgets, the
compiler developers focus their efforts on the most common code
patterns, because that's where they get the most leverage.”
While most developers strongly agree with you, two Java Champions have made relevant points about this. Matjaz Juric has observed that code execution speed is becoming less and less of an issue as servers and computers increase their speed, so your point is not as strong as it once was. And Yakov Fain says that if hacked-up code produces great results, apply it without worrying whether other developers will understand it. He describes running a seminar for Java developers who gave him the impression that implementing MVC had become an end in itself. He insists that using Design Patterns should not be a dogma. Your response?
While most developers strongly agree with you, two Java Champions have made relevant points about this. Matjaz Juric has observed that code execution speed is becoming less and less of an issue as servers and computers increase their speed, so your point is not as strong as it once was. And Yakov Fain says that if hacked-up code produces great results, apply it without worrying whether other developers will understand it. He describes running a seminar for Java developers who gave him the impression that implementing MVC had become an end in itself. He insists that using Design Patterns should not be a dogma. Your response?
A: I think both developers are not really responding directly to my
point, so let me clarify. We all know that, all things being equal,
cleaner code is better than dirty code. My argument was that the most
common excuse for writing dirty code was because of perceived
performance benefits, but unfortunately most code atrocities committed
in the name of performance don't even have the desired performance
effect and are, therefore, frequently counterproductive. Matjaz Juric's
observation only strengthens this point, by pointing out that a lot of
the time, in part due to faster hardware, additional performance is
not a business requirement, so one should not pay anything for that.
Yakov's point is fine as far as it goes -- there can always be extenuating circumstances where doing the "right" thing isn't necessarily right. Of course, it takes experience to know when to break the rules. If you are truly getting "great results," then keep doing what you are doing. But you need to factor in future maintenance costs and failure risk to the perceived "greatness" of your results. (If you decide to cancel the insurance policy on your office building, your monthly profit-and-loss results may appear great, but only in months where the building doesn't burn down.)
Yakov's point is fine as far as it goes -- there can always be extenuating circumstances where doing the "right" thing isn't necessarily right. Of course, it takes experience to know when to break the rules. If you are truly getting "great results," then keep doing what you are doing. But you need to factor in future maintenance costs and failure risk to the perceived "greatness" of your results. (If you decide to cancel the insurance policy on your office building, your monthly profit-and-loss results may appear great, but only in months where the building doesn't burn down.)
|
|
“I’m very excited about
JSR-292, the so-called ‘InvokeDynamic’ JSR. JSR-292 is about identifying
aspects of the JVM architecture that are overly tied to the Java
language and making them more general, eliminating the pain points for
many non-Java languages on the JVM, such as JRuby, Jython, JavaScript,
Scala, or Groovy.”
Java Language Architect, Oracle |
JSR-292 – InvokeDynamic: Making the JVM More Accessible to Other Languages
Q: What features of Java SE 7 are you especially excited about?
A: : I’m very excited about JSR-292, the so-called "InvokeDynamic" JSR.
JSR-292 is about identifying aspects of the JVM architecture that are
overly tied to the Java language, and making them more general,
eliminating the pain points for many non-Java languages on the JVM,
such as JRuby, Jython, JavaScript, Scala, or Groovy. JSR-292 provides
low-level VM machinery that compiler writers can use to interact more
deeply with the VM, so they can share information with the VM that can
be used to make optimization decisions. This provides tools for
addressing the most common performance issues for non-Java languages,
such as the cost of dynamic method dispatch or open classes. JSR-292
also includes VM features that will be used in Project Lambda, enabling a higher-performance implementation of closures than was possible using only inner classes.
An Update on Java Concurrency
Q: In 2007, you also said that Java developers should understand
that concurrency is hard but not impossible. You remarked: “People tend
to go from one extreme to the other, from thinking, ‘This is easy -- I
just synchronize everything’ to ‘This is impossibly hard.’ I disagree
with both. With concurrency, developers should realize that they have
to be careful, think hard, and have someone review their code.” Would
you care to revise this?
A: The basic sentiment is still right, though there are techniques
which can reduce the surface area of the difficult parts. Not only do
improved libraries provide pre-baked versions of common idioms, but
developers can often sidestep the complexity of concurrency by limiting
shared mutable state in their programs. If you don't have shared state,
you don't have to coordinate access to that state, which is where the
trouble comes from. Functional languages are built on this principle,
but we don't have to switch languages to get the benefit -- we just
have to adopt the orientation that immutable state is better than
mutable state, and seek to increase immutability and decrease sharing.
In Java SE 7, we’ll be adding a framework for fork-join decomposition,
which makes it easier to write algorithms that parallelize
automatically across a wide range of hardware configurations.
|
|
“The mission of Project
Coin was to identify small language changes that could be considered
‘rough edges’ in need of filing down. The work engaged the community to
suggest features and provide specification and implementation; there
were nearly 50 submissions from which a half dozen were accepted."
Java Language Architect, Oracle |
||
|
|
"I am currently working
on Project Lambda, which is providing closures (and a set of related
language features) for the Java language, as well as upgrades to the
core Java libraries to more easily express parallel calculations on
calculations."
Java Language Architect, Oracle |
Language Enhancements in Java SE 7 and 8
Q: You have a new role at Oracle as "Java Language Architect." What
can you tell us about this new role and what is coming for the Java
language in Java SE 7 and 8?
A: This is a really exciting time to be involved in the development
of the Java language. The last batch of language enhancements came in
Java SE 5; we've got new features coming in both Java SE 7 and 8. In
Java SE 7, we have a number of language features developed through
OpenJDK's "Project Coin,"
which has been a real community success story. The mission of Project
Coin was to identify small language changes that could be considered
"rough edges" in need of filing down. The work engaged the community to
suggest features and provide specification and implementation; there
were nearly 50 submissions from which a half dozen were accepted.
Some are really simple, such as more flexible lexical specification
of integer literals, while others create new language constructs that
make common idioms smaller and less error-prone, such as the
try-with-resources statement.
There's some really good stuff coming in Java 8, which isn't as far
away as it sounds. I am currently working on Project Lambda, which is
providing closures and related language features for the Java language,
as well as upgrades to the core Java libraries to more easily express
parallel calculations on collections. The other big feature coming out
of Lambda is virtual extension methods, which address the long-standing
problem that once an interface is defined, you cannot add new methods
to it without breaking existing implementations.
As Java libraries age, this becomes a bigger and bigger concern.
Other languages have addressed this with traits or full-blown multiple
inheritance, but we did not want to fundamentally change the Java object
model. Extension methods let you add methods to interfaces that
specify a reference to a default implementation, so in the event a
class implementing that interface does not provide an implementation of
that method, the default is used. These interface methods are full
virtual methods, so implementations can provide better implementations
than the default if they want to. I'm very pleased with how this
feature is shaping up, because it provides a great deal of additional
flexibility without creating too much additional complexity, as more
major surgery to the object model would do.
While extension methods are not directly required for supporting
closures, the addition of a feature such as closures to the language
puts pressure on the libraries, because with closures in the language
it becomes far more desirable for the Collection type to include, say, a
forEach() method. So Lambda expressions became the last straw that pushed us to revisit the flexibility of inheritance.
But the real push behind adding closures at this point is the trend
towards multicore. Without closures, the collections classes can't
easily offer internal iteration, so the
for loop becomes the only way developers have to iterate through a collection. And the for
loop is inherently serial. So the current state of language+libraries
is driving developers towards serial idioms, which puts developers on a
collision course with Amdahl's Law.
Q: How can developers contribute to the project?
A: All our development is taking place in the open. Project Lambda and Project Coin
are both hosted at OpenJDK, and the mailing lists are open to the
public. We've gotten lots of feedback from the community already.
The JVM Language Summit
Q: You helped host the JVM Language Summit,
which was held on July 26-28 of 2010. How would you assess the state
of the art of language design and implementation on the JVM, and the
present and future capabilities of the JVM itself?
A: The JVM Language Summit has been a fantastic success. For the
last three years running, we've had an amazing collaboration between VM
developers (with architect-level representation from all three major
commercial VMs) and language designers and implementers. Much of the
discussion has fed directly into the JSR-292 process. The JVM has always
been a good platform for implementing languages, but there have always
been pain points because the JVM has a small number of aspects that
are Java-specific, though fewer than you might think. But through the
collaboration with language developers, we've been able to reduce the
size and impact of these areas of mismatch. If I were building a new
language today, there's no way I would consider writing a native
compiler -- I'd much rather target the JVM, and get portability,
garbage collection, high-quality compilation, concurrency control,
tools, serviceability, and lots of other features for free.
See Also
No comments:
Post a Comment