Following is the text transcription of this interview:
Joshua, can you tell us about your involvement with Java over the last few years?
I came to Sun to work on Java in 1996 because, as you'll recall, back then, it was where all the action was happening, and the 1.0 release had just gotten out the door, and the first JavaOne had just happened and it jumped right into the 1.1 release. I was originally working in the security group, gravitating actually to the core platform group because I've always been involved with core platform elements, code reuse and I found that there was a great opportunity to do that here, basically to design APIs for everone to use. So in the 1.1 release I designed java.math which is the multi-precision integer arithmetic and fixed point decimal arithmetic package as well as a few other little things having to do with concurrency. And in every major release of the Java platform, that is, the J2SE platform, since then, I've contributed to one or more features. Also, I'm the author of the Jolt award-winning book called the 'Effective Java' programming language guide.
What initiatives are you involved with currently?
I'm involved in several Java Community Process JSRs. Perhaps the most exciting one is JSR 201 which has 4 new language features. These are probably the first major language features added since inner classes in 1.1, if you don't count assertions which I didn in 1.4. Also, I'm involved in JSR 175, which is a metadata functionality for the programming language, JSR 166, which I'm not leading, Doug Lea of SUNY Oswego is leading that JSR. It is adding concurrency utilities to the platform. And (I'm involved with) several other JSRs but those are the main ones.
Tell us about the new language features defined in JSR 201?
There are 4 of them. One is the Type Safety Enum feature. This is actually covered as a pattern in my book, 'How to do Typesafe Enums on top of Ordinary Classes.' But it is unfortunately somewhat verbose. So to do an Enum in a language like Pascal, or C++, or C#, you just say Enum Season {Winter, Spring, Summer, Fall}. Whereas to do a Typesafe Enum Pattern in Java, it was a large quantity of verbiage. Now you got a lot more power out of that because it was a real class you could put into collections, you could add methods to it, add fields to it, but unfortunately it was also somewhat more difficult to use. So this feature basically combines the power of this pattern that's described in my book with the expressivity and the ease of use of the standard Enum construct of the sort that you'll find in other languages. Most of those you'll find are merely glorified integers. They aren't type-safe, they aren't very powerful. So this one will be far more easy to use and more powerful. There is a for each feature which is very simple. It is basically just a loop that let's you iterate over a collection or an array without explicit use of an iterator variable or an array index, when you don't need it.
Then there's autoboxing. As you know the Java type system is divided into two parts: the primitives and the objects. And in order to put a primitive into a collection you first have to box it. So an int goes into an Integer, a float goes into a Float, and so forth. And it makes for code that's a little bit messy, because you have to cast these things both going in and out of the collection. So with autoboxing you don't have to have those casts anymore.
The fourth feature is static import, which is a fairly simple feature. Currently, in order to access any static member of a class, whether it's a static field or a static method, you have to explicitly prefix it with the class name. So for instance math.pi or math.cos. And that is somewhat verbose and in particular it causes people to use an unsafe pattern. When people want to use a bunch of constants, instead of putting them in a class (and prefixing them with the class name), they put them in an interface and implement the interface to get all of its constants. But unfortunately that changes the public API of the class doing this trick because that class now implements this interface. And so what you want to is be able to do is use these static members without explicitly prefixing them. So what we're doing is we're adding an import statement much like the one that currently exists to import package members that allows you to import the static members of a class.
The JSR 14, Generics, is also scheduled for the Java 1.5 release. Can you tell us more about the motivation for Generics and how it will impact Java developers?
Generics is probably my favourite new feature that's coming in 1.5. The motivation is that currently, when you have Collection data types in Java, they are in fact Collections of Object and whenever you take anything out all you know is that it's an Object. And if you want to make it something more specific, you have to cast it explicitly. And if there's an error, so if you think there's a String in there and you cast what you've got out to a String, but in fact it's an Integer, you don't find out until runtime when your program blows up in the field. Now what Generics does for you is it takes that error and it moves it from runtime to compile time. So if you tried to take a String out of a collection of Integers, your program won't even compile any more. And furthermore, it eliminates the need for explicit casting. You declare the collection as being, say, a List of String rather than simply a List and then when you get an element, you get a String rather than getting Object and having to cast it to a String. And since you have no explicit casts, you have nothing that can fail. In fact, there are casts under the covers; the compiler generates them for you. But they don't fail; they are guaranteed to succeed.
Do you find people weren't using collections to store multiple types?
They occasionally do but typically there is a least common supertype. So you can still bound the types. That is, Generics buy you something unless people are really storing absolutely arbitrary elements in a collection, and as you probably know, they tend not to do that; I would say 90% of all collections are collections of Strings. And then you have Maps from whatever your key type is to whatever your value type. But far more often they will be used in a homogeneous fashion where all of the elements are of the same type.
What is the overall philosophy behind these language changes?
So basically what this does it takes the common uses, and makes them safer and easier. It takes things that you used to have to do by hand and it does them for you automatically. This a common theme running through a lot of the language work that's coming in the Tiger time frame. Many of these features take patterns that people used to have to code by hand, using boilerplate code, and they do it for the programmer, allowing the programmer to concentrate on their problem, the business problem that they're solving, rather than these low level details of how do I make the Type Saftey Enum pattern work properly. And not only do they make it easier, but they make it safer. They make the programs more robust, more reliable, because of the fact that when you have one of these patterns, you have a lot of lines of code and if you enter them manually you can make errors, cutting and pasting, and you have to change certain variables to that they match on separate lines. And if you only change two of the three things that you've got to change, then you have a program that doesn't work and it might compile, but it might not run. So if all this stuff is done automatically for you, then you have fewer opportunities to srew up. And moreover, the program's more readable, because instead of having all this verbiage, all you see is Enum Season {Winter, Summer, Spring, Fall}. If that's what you see, it's clear what you're trying to do.
Are there any parts of the Java language you would deprecate or remove?
There are things I would change. For example, I think the Switch statement should have been more structured. I don't think it makes sense to have a fall through from the Case as was the case in the C programming language. There are certainly individual libraries I think that could stand to be improved, and some removed. Some really have no use any more, for example, anyone who's read my book knows that I think ThreadGroup has basically outlived its usefulness. And I think for any system with size and complexity the honest answer to that question would be yes. When you grow a system of this size over this many years, it will have warts. But what you have to do is look at it as a whole and I think you'll find that Java hit a sweet spot in 1995 and it pretty much stayed at that sweet spot while growing and becoming more richer and powerful over the past 7 years.
Where does the inspiration for these changes come? Are you looking at other languages as models or are these standard items in computer science that have been researched?
They're standard items with some exceptions. But making them work properly in the context of any given language is tough. And I have great respect for the original Java designers, as you know, Gosling and his team when they designed the language, which was then known as Oak, decided not to include some of these features, for instance, Enums, because the patterns as they were implemented in those days weren't satisfactory. They knew that, and they figured, rather than putting in something that isn't exactly what you want, let's wait until we know how to do it right and then let's put it in. So for example, Assertions were going to be in Java in the early days. If you look at the earliest specs for Oak, you'll see them there, but they didn't quite know what they wanted to do or how to do them properly. So they weren't put into Oak and they were added later, and most of them have that character. For instance we've known we wanted to go Generics for years but we haven't exactly found the right combination of features and functionality. Generics in particular is a tough one because you have to prove the type system is sound and correct and that really is Rocket Science. In fact we have a team of computer scientists at various universities who are working to make sure that our solution is exaclty what we want.
Can you tell us more about the people behind the scenes; you mentioned universities. Who's driving the Java language?
Well it is the Java Community that is driving the Java language. Of course there's Sun Microsystems and you know the names of a lot of the major players, the people who are spec leads on these JSRs, Mark Reinhold, myself, Neal Gafter who is doing various compiler related ones and a host of others. And then there's, sort of, a core of interested parties. So for examples you'll see names like Doug Lea from State University of New York at Oswego pop up all the time. He's been involved with the language since its earliest days. He's been one of its most ardent supporters in academia and he's contributed much in the way of ideas and APIs. You'll see a number of our people from industrial partners, from IBM, Oracle, Borland and it sort of pains me to list individual companies because there are so many of them that I can't do justice to all of them. But basically, there are major players in all of the areas that you would expect. There are people from the open-source community, the industry, academia, and of course Sun.
How would you personally compare Java 1.5 to C# as it currently stands?
I think it's a better language. It's smaller, simpler, more standard, that is, more based on open standards. It has a larger community amassed behind it, a larger mass of libraries written for it, tools written for it. Certainly, given the choice, I'd rather program in Java.
Why haven't you added popular features which are being discussed today such as Aspect Oriented Programming?
Clearly imitation is the sincerest form of flattery. C# is a lot like Java, they've clearly learned a lot from us. But they had a bunch of legacy systems they had to support, and threw in everything but the kitchen sink. We haven't done that and we continue to resist that. So if you look at the new changes, you'll see that they are small, that they are carefully targeted, and we don't mess with the core of the language. We don't mess with the JVM, and we don't mess with the sweet spot, the flavour of the language. Java has always combined simplicity with power in a unique way and because of that it's always appealed to a broad mass of developers and we don't want to lose the support of those developers. So every release, people ask for many many many things, we get thousands of RFVs and only the ones that are the strongest, most free of risk are going to make it into the language. There are many good ideas like Aspect Oriented Programming which are great and we're glad that people are doing them, but they're research and once they're battle tested for 10 years, well maybe they'll have a place in a production language. But if we put in every new featured that we're asked to put in, the language would quickly get out of hand. I remember a talk that Gosling gave around 1998 where he basically said that unless people could give him 3 compelling uses for a feature, we wouldn't even think about putting it into the language and I try to continue in that tradtion.
Is there any message you'd like to get across about these new features and about the Tiger Release, Java 1.5?
There's one message. It's that I'm excited about them, that I'm thrilled to have the opportunity to participate in this growth of the language because all of these new features combine in ways to make the language really much more pleasant to use. And there are things that I've wanted to do for years. When you're growing a language it's very important that you grow it organically, that the features interoperate well and because of the fact that there are overlaps among the expert groups doing these features and they're constantly communicating (so that) all these things combine harmoniously. So for example, we have the for each feature to allow you to easily iterate over collections and we have Typesafe Enums. And the Typesafe Enums will export, their 'universe', that is, the set of enumeration constants as a collection so you can use for each to iterate over them and you can combine this with Generics so that you don't have to explicitly cast. And once you've done all of these things, things that would've previously taken 20 or 30 lines of boiler plate code, now take a line or two and they're crystal clear. I've had the opportunity to already program in prototype implementations of some of these and I find it thrilling and I can't wait to see other people smile when they first try it.
What you're saying about Java 1.5 sounds a lot like what I'm hearing out of Oracle, where their aim is to delight the developer.
Yes that's exactly right. You do want to delight the developer. But not only do we want to delight the developer, we want to delight his manager. Not only should it be more fun for him to develop code but he should be more productive and his code should be more free of bugs. And I think that's precisely what these features do. They increase the ease of development, they increase the power, they increase the productivity of the language.
