HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

On a late sunny Tuesday afternoon, James Gosling, the creator and father of Java, takes time out to chat with JDJ's Alan Williamson and Blair Wyman.

Williamson: How are you finding JavaOne so far?
Gosling:
There's an awful lot of energy here and just seeing what people are up to is a lot of fun. As we go from year to year, things are moving at such a quick pace. Seeing how much stuff is incredibly real these days is quite a rush.

Williamson: Are you still involved with Java?
Gosling:
It's my job, every day.

Williamson: We can't imagine you sitting there in front of a compiler; do you?
Gosling:
Actually for the last couple of months I've been tormenting the guy who owns the compiler source and I've been hacking on it relatively heavily. But I think someday he will forgive me.

Williamson: What's the big surprise this year when you walk around all the booths and exhibitors?
Gosling:
The thing that I get the biggest kick out of is all the stuff that is now in shrink-wrap boxes. When we did that goofy shopping videotape, none of those devices were fakes; none of them were balsa blocks. They were all prototypes. They were all shipping in volume shrink-wrap gizmos; it's just terribly real. A year or two ago when we were talking about these devices, it was of academic interest to most people there. To the people who were actually building it, it was very interesting.

Today it's a completely different game because anybody here at the forum can really enjoy the feedback. It's nice to have the U.S. headed out of being a third-world country in terms of its phone system - you can go to a phone store in San Francisco and buy a Nextel phone. You can go to the Motorola Web site and get the developer kit. There's a little handshake you have to do, but it's relatively minor and you too can hack your phone set, you too can build an app that does anything from video games to enterprise data stuff that goes end-to-end.

Williamson: With respect to the whole spectrum of Java, it's now covering a tremendous amount of space there. Which particular area is now ringing your bell?
Gosling:
I tend to be a science geek, and for the longest time I was Mr. Everything Except Enterprise. All kinds of things ring my bell in that area. A while ago I visited the Keck Observatory at the top of Mauna Kea and saw how Java has really taken over. The giant telescope crowd and the tools they're building are just incredible.

My first paying job was working for a group of physicists writing satellite data acquisition software for the Isis 2 satellite - that was a real rush. Seeing people doing this kind of stuff is pretty amazing.

Williamson: Java is a wonderful language; it's your child, I think people would agree .I'm just wondering, are there still any warts on your child that you'd like to see removed? Are there any problems in Java that you think need fixing or changing?
Gosling:
The answer is yes and no. In some sense people are being very successful with it. In another sense, if I had a clean slate and was doing things differently, there are many things that would come out differently. I actually have a small Web site that's this long laundry list of things that would be entertaining. It goes from, yeah that might be worth doing to that's truly goofy. A lot of these things are pretty hard design trade-offs. A lot of engineering is not a black-and-white choice - this is the right thing to do and that's the wrong thing. It's similar to Whackamole, a game you play on the Santa Cruz boardwalk and various other places. There's a big board with a little mechanical mole that sticks his head out of the ground and you have a big baseball bat that you whack it down with, but he pops out somewhere else.

A lot of program design (and any other kind of engineering) is like that. For instance, many things about the basic notion of a class-based system in which you have subclassing and inheritance of implementation have issues. You can get around some of that with different styles.

Actually Josh Watt came out with this book called Effective Programming. It contains information on how to think about object-oriented programming and how to avoid some of the pitfalls we've discussed over the years. For example, one of the solutions that often comes up is: throw away object-oriented computing completely and go for something along the lines of delegation models that some people have used - it's similar to class inheritance but somewhat different. It solves some problems, but creates its own. There are things to be uneasy about but no clear answers. You could do all kinds of interesting experimentation.

Wyman: You spoke of being a science geek. Do you see Java playing in that space? Do you see it compete against FORTRAN, or what was your satellite acquisition software written in?
Gosling:
PDP8 assembly code.

Wyman: PDP assembler, wow!
Gosling:
That dates me, right? A PDP8 has less compute power than your average smartcard.

Wyman: Is there much PDP8 code in Java?
Gosling:
There's some learning from writing PDP8 code. I had been programming for a number of years before I found a machine beefy enough to run FORTRAN. By then I was writing CDC6000, 7000 assembly code. The cyber series and its predecessors were pretty hot. It was almost like half an MIP.

Wyman: MIP is meaningless information for product salespeople?
Gosling:
Yeah, exactly. ;-)

Wyman: In the science arena, do you see the megahertz catching up to make Java effective in a real-time programming environment?
Gosling:
It's been effective in real time for quite a while. Lots of people have been real-time programming in Java for years. The issue has never been megahertz and speed. If you talk to real-time people, they hardly care about speed; what they care about is determinism, namely, when it's time to adjust the flutter on the F16 wingtab, I want to do it now please.

Wyman: So no GC cycle then? ;-)
Gosling:
No, no waiting for the garbage collector to be done with its business. No waiting for the paging system. No waiting for the kernel to context-switch out of the sendmail daemon. When you've got to pull the cadmium rods out of the reactor core, you have to do it now.

Williamson: One thing that we've been speaking to all the vendors about, and one thing they've said is that it's nice to see that there are no major new announcements with respect to Java. It's as if Java is maturing to a state where we're now actually using it, and we don't need to help it any longer. In that respect it's cool to see Java now reaching in. Where do you think Java is going in the next 12 months?
Gosling:
That comment about no major announcement feels kind of weird because when I listen to some of the things that are going on, maybe one of them, four or five years ago, would have counted as a major announcement. There's now such a high threshold for a major announcement.

Williamson: Seriously impressive type of situation going on now.
Gosling:
Yeah, it's like, "Oh gee, Mr. Nokia, only 100-million cell phones, that's boring." We've gotten jaded these days.

Williamson: Isn't that a sign of the language maturing though?
Gosling:
Well, it's sort of maturing and engaging and it's a community thing. We've been trying to get to the point where Sun is not the driver of Java, and I think we've been pretty successful at it. The really cool stuff in Java is not happening at Sun. We haven't been slowing down in what we're doing; the rest of the world has been ramping up. Would class, as a really huge announcement, be like the uptake in MID-P?

What people are doing with development tools, the Java faces thing, there's a way to do a UI toolkit that's supported by IDE tools, yet projects its UI across the Web. That sounds to me like a pretty major announcement, but it's not us doing it. It's not guys with Sun badges doing most of the design and the work. It's people from Borland, WebGain, etc., who are doing it.

Williamson: How do you feel about the overall issue that's often debated in newsgroups about open sourcing Java?
Gosling:
If I actually knew what people meant by open sourcing, I might be able to answer the question. In a strong sense it's been open sourcing from the beginning. We've always shipped the source; anybody who wants it can easily get hold of it. The thing that blocks the zealots calling it open sourcing is that there's actually something that we care about: if somebody has a Java program, and somebody else has something that they call a Java platform, the program ought to run. So we get uptight about that particular point. On average, developers actually care about that, they seem to think that that's a good thing. Yet the open-source community pillories us. Our license is identical to any of the other open-source licenses, but we have these catches that are mostly about interoperability.

Williamson: Another hot question we get asked is, back in December 1990, it was released as Java2, but it was actually 1.2. Now it's going to 1.3. Where does this Java2 come into it?
Gosling:
Marketing guys, what can I say! 1.2, 1.3, 1.31, that's the numbering scheme in the source-code system; that's the numbering scheme that the engineers actually believe.

Williamson: Will we ever see it bump into 2.0?
Gosling:
Beats the crap out of me.

Williamson: I heard 1.4 is around the corner at the end of the year. Then I heard rumors that Tiger 1.5 is now starting to have some serious development.
Gosling:
I've been working on the Tiger complement for several months now.

Williamson: Anything you can tell us about that?
Gosling:
Nothing useful. On the piece I've been working on are applications, other than the compiler, that would like to use the guts of the compiler. I got into this because I was building a tool that could play with the animated graph. I had built myself yet another Java compiler clone because I wanted to get at the syntax tree, but that seemed kind of goofy because the compiler we had is nicely structured. All it needed was for its innards to be exposed as an API. What I've been working on for the last couple of months is cleaning up the guts of the compiler, so it could be an accessible API.

Wyman: You speak of the JavaC compiler and expose it at an API level, or is it too soon to talk about it? Would you be able to give me the parse tree and show me the nodes and all the goodies?
Gosling:
Yeah, that's what it does now. There's this question of what to do with it. We got started on it because that compiler is officially a Sun product and we needed it. The question is whether to just sail on doing that or start a JCP group to figure out what to do. We've got a first cut at an API, but we'll have to talk to people to find out what kind of interest there is. For me, I'm doing it because I needed it, whether it turns into part of the product is another question.

Wyman: Do you see any changes to the Java Virtual Machine specification underneath the Java language? To extend any of the architectural limits that exist in the byte codes?
Gosling:
There are actually remarkably few limits. We have this long laundry list of things that would be cool to do, most at the language-level. It's interesting to see how few of them have any impact on the virtual machine. The number one and two language requests have been generics and assertions and neither of those require BM changes.

There's a number of them, one of which I'm particularly hot on called immutable objects: a way to declare an object immutable. It means to declare that a class is final with all final fields, but with a twist - the quality operator is somewhat different. The motivation is that a sufficiently good optimizing JIT can optimize away the existence of these objects. So if you did something, such as complex numbers in terms of immutable objects, you could end up with code that did complex numbers as efficiently as FORTRAN.

Right now the big blockage in getting C++ or Java performance up to FORTRAN in a number of these numerical issues is that there's a limit as to how far you can optimize the primitive objects. In particular, the major block is that they still have an identity as an object. If you can get to where the notion of identity disappears so EQ goes away, you have only equal, and the things can mutate, then you can do copies arbitrarily, which is the number one thing you can do to allocate objects into registers where they aren't really objects, just things that live there momentarily. The things that you can do are pretty terrific.

Wyman: Like a new pseudo-primitive.
Gosling:
Yeah, although there have been about a dozen sketches like that done, it's actually possible to properly do it so it actually doesn't affect the Java VM specification at all. I mean that in the sense of correctness, namely a correct VM would just ignore it, but then these immutable objects would be allocated like regular. However, if you really wanted to take advantage of this, there's a huge amount of work in the optimizer. Then you could start doing things like 3D graphics at unbelievable performance because with things like point beta structures, you could do some very amusing optimizations with them.

Wyman: As a big Mandelbrot set fan, I would love to see a complex as a pseudo-primitive.
Gosling:
You can certainly do complex numbers now, the issue being that you can't get to FORTRAN optimization level with it. One answer to it is to make complex be a primitive the way FORTRAN does, but to do something that has the same optimization opportunities, that's general enough, so you can define complex for use in your Mandelbrot sets. I can define 3D points for doing constructive solid geometry and I get exactly the same kind of rocket optimization.

Wyman: Is the automatic optimization in JavaC and other compilers? Do you see the dynamic versus static issue anymore? There used to be a real issue doing static analysis of a program because you always had to worry about something slipping into the classpath at runtime. But static analysis is precluded by that dynamic nature, wouldn't you say?
Gosling:
You can do static compilers and get the dynamics right, the problem is that it's difficult and the people who built static compilers were on the lazy side. The average static compiler was built by retreading someone's C compiler's back end and all kinds of funny things creep in. Dynamic compilers have gotten a lot better and they're pretty consistently beating the static compilers; since they know what your program is doing and what chip it's running on, they can do a lot more interesting things. They know what's loaded in, and it's been interesting watching the evolution of the programming style as it constructs large systems because more and more of what people do to construct systems is they don't build a big monolith; they build a spine that's a central place where things can plug in.

A Web server is a prime example, the way the Tomcat works with plug-in JSP pages and servlet pages. EE this and who knows what else. People roll in their own APIs all over the place. As a general technique for building flexible systems that can dynamically upgrade and all that kind of stuff, it's used all over the place. It's hard to find a Java program that doesn't use dynamic loading. Many people aren't even aware when it happens because with many of the underlying systems doing it, things like localization, they'll dynamically link in stuff, depending on where you happen to be. You don't have something where all the kanji you type in modules are now loaded for almost everybody; for the folks in Japan, it's right there, so you get what you need.

Williamson: Well, James, thank you for taking the time out to talk with us, and we look forward to seeing you again in September at JDJEdge.

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.