 | |
java.sun.com (JSC): James Gosling, in January of 2007, wrote in his blog, "Throw stuff into the kitchen sink without thinking too hard about whether or not it's a good idea. Let folks kick the tires. Those experiences then inform the choice of which features go into the standard." In that spirit, you have started the Kitchen Sink Language (KSL). Tell us about it. Ahé: KSL is a java.net project in which you can modify javac, Sun's Java compiler. Before we open sourced javac in November, a lot of people warned us that open sourcing the Java programming language would lead to a lot of forks in the language. I'm not concerned about that because I think everyone in the Java community strongly believes in compatibility. There are already open-source Java platform projects such as Apache Harmony, GNU ClassPath, and the Eclipse compiler (JDT), all of which are committed to compatibility. However, experimental branches of the compiler can help us evaluate language proposals, as long as we know they are not part of the Java programming language yet. James and I agreed that it would be better to lead by example rather than hoping there would be no forks in the language. I'm really excited about KSL and hope it will serve as a nursery for new ideas. Recently, I have been involved in a proposal for adding closures to the language. Neal Gafter has produced a high-quality specification for this proposal. No matter how good the specification, trying it out on your own code provides better understanding. The compiler team has always been very open. In fact, when Neal worked for Sun, he started releasing javac under the Java Research License (JRL) so that academics could use it as a base for research. He also suggested the weekly snapshot builds of the platform, which really helped improve the quality of JDK 6.
JSC: You were the spec lead for JSR 199, the Java Compiler API, which is now included in the Java SE 6 platform release. It allows a Java program to programmatically select and invoke a Java compiler. Danny Coward, the Java SE 6 platform lead, said, "For those of you deafened by your screaming inner geek, roll up your sleeves and give it a try." Ahé: Although most developers do not want to know how to use the Java Compiler API, it will provide a lot of indirect benefits. For example, Project GlassFish could speed up compilations by taking advantage of the API, which should cut down deployment time, something many developers would welcome. In fact, the entire tool chain that developers use involves a lot of compiler technology. The combination of JSR 199, JSR 269, and our Compiler Tree API allows IDEs such as NetBeans to take advantage of the compiler technology. Most Java developers are going to be excited when they experience the new Java editor in NetBeans IDE 6.0.
JSC: In your blog, you have identified problems with generics related to the lack of runtime type information about generic types. You point out that at runtime, you cannot tell an Ahé: Let me provide some background on generics. When we added generics to the Java programming language in 2004, it was based on a technique called erasure, which had been selected many years before because it was the only proposal that dealt with migration compatibility. As of 2004, after more than five years of work in academia and at Sun, there was no known solution that could solve all the compatibility requirements. Jon Gibbons joined the compiler team around the time we shipped JDK 5.0 and offered a solution -- or at least a restatement of the problem. Rather than trying to provide reified types for all instances, why not simply accept that some instances do not have reified type information, because they are compiled with a 1.4.2 compiler or for other reasons? This turns reification into a best-effort problem: If you use a raw type, then no type information is reified, but if you avoid raw types, you can take advantage of the additional reified type information. It's worth noting that a precondition for Jon's idea is that it is worth having erasure. Today's generic types would not exist without erasure.
JSC: Tell us about your proposal for an alternative to type inference for local variables. Ahé: Part of the proposal involves removing the type from variable declarations -- on the left-hand side of an assignment. This promotes programming to classes rather than interfaces. Generally, I recommend programming to interfaces because it provides the option of later switching the implementation class if you find a better implementation. Another problem with removing the type of the variable is that although it makes it easier to write code, it makes it harder to read code. Because code is written once and read multiple times, it's important that we do not add features that make code hard to read. So how do we solve the problem, which amounts to repeating yourself and making your code harder to write and read? It connects with another pet peeve of mine: For better flexibility, most classes should provide static factory methods instead of public constructors. But adding static factories that duplicate your constructors in existing classes is not optimal either, so why not have the compiler provide the static factories for you?
JSC: Tell us about your Java SE 7 wish list. Ahé: Now that we have open sourced javac, people should be playing with it. Imagine my surprise when Rémi Forax began granting my wishes. One of the marvels of being open source is that you get so much back from the community! JSC: What are the biggest misconceptions you encounter about javac? Ahé: That javac is a build tool. It is a compiler -- use
JSC: Tell us about your first encounter with Java programming. Ahé: It was when I found a button applet on the web. I modified it slightly so that it said, "Go to my home page," and put it on my home page. The button was rather funny because as the mouse cursor got near the button, it would move away. JSC: What do you do when you feel stumped? Ahé: I explain the problem to a colleague. It doesn't matter if they understand it. Sometimes just the act of verbalizing the problem enables me to see the solution.
JSC: Do you have a favorite Java technology story? Ahé: Yes, the one about how I became a Java compiler engineer. As a student, I had a part-time job as a systems administrator in the computer science department that required a lot of skill. I decided I needed a better title for my resume and started interviewing for part-time software engineering positions so I could refer to myself as a programmer. At a job interview, I discussed my programming skills, including Java programming, because I had successfully modified the button applet a few years earlier and had a good understanding of similar languages such as C++, Self, and Beta. I did not really have the experience, but I knew it would not matter because they were not looking for a Java developer -- except they were! So I had some learning to do. Six months later, a computer science professor asked me to join him in a research project adding wildcards to the Java programming language. So that is how I became a Java compiler engineer. JSC: Where in programming do you have the most fun? Ahé: Fixing compiler bugs. JSC: Where in programming to you encounter the most grief? Ahé: Fixing compiler bugs. JSC: If you could work on a dream project, what would it be? Ahé: If you had asked me four years ago, my dream project was javac. Now it's closures or reification. JSC: What is the Java class you could not live without? Ahé: JSC: What recent changes to the language have made your life easier? Ahé: Overall, changes to language features do not make my life easier. Hopefully, they make a lot of other people's lives easier and perhaps able to write better applications so my mom will stop calling me for software support.
JSC: What is your favorite Java technology book? Ahé: Effective Java by Joshua Bloch. JSC: Any tips about writing better code? Ahé: Read Effective Java. Write lots of tests. JSC: Your advice to someone just starting out as a Java developer? Ahé: Read Effective Java. JSC: Finally, tell us about your plans for the 2007 JavaOne conference. Ahé: I like talking to the developers, and the best way to do that, in my opinion, is the Birds-of-a-Feather (BOF) sessions. I have two BOFs this year:
Peter von der Ahé's Weblog
| ||||||||||||||||||
|
| ||||||||||||
Print-friendly Version
