|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?
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.)
Java Language Architect,
JSR-292 – InvokeDynamic: Making the JVM More Accessible to Other Languages
Q: What features of Java SE 7 are you especially excited about?
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.