Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters

Email Address:

An interview with James Gosling

Bill Venners probes the formidable mind of Java's creator

JavaOne Today: What have you been working on recently here at Sun Labs?

Gosling: These days, I'm putting together a group to work on developer tools based on work done by the NetBeans folks, who put together this really nice framework for building tools.

One of the things I'm trying to do is to build a set of tools that professional developers would use. Typically, tool vendors tend to go after the mass-market developer, and I guess I'm not one of them, so they generally don't interest me. And, by and large, all the tool developers have kind of ignored the higher-end developers. So I'm spending some time thinking about that.

But, in actual fact, I've spent most of the last year working on the realtime spec for Java. That's really what's occupied me for most of the last year. I was doing that pretty much full-time until three or four weeks ago, when we finally got a camera-ready copy of the book off to Addison-Wesley.

JavaOne Today: Which book?

Gosling: The realtime specification for Java. It's a spec that was done under the Java Community Process. JavaOne Today: Could you give an overview of what's in that spec and what it's all about?

Gosling: The realtime spec for Java is all about how you write programs in Java on realtime systems. And there are a number of components to it -- simple things like dealing with accurate dates, scheduling events. Most of the hard things have to do with deterministic timing.

James Gosling



In the realtime world, what people care about is performance, to a certain extent. But more important than performance is, generally, determinism.

When you say, "I want this to be executed at that time," in general, by God, you mean it. And then it's not allowed to slip. And that has effects in two areas. One is scheduling, and there's all kinds of exotic scheduling algorithms that can be in there, and the realtime spec has a general framework for putting in all kinds of schedulers.

The other side of it is that there's one big source of non-determinism in timing in Java right now, and that's garbage collection. And garbage collection is really the number one hard problem.

On the one hand, people look at garbage collection and what it gives you, and they by and large really like it. Particularly folks in the realtime world like garbage collection a lot because it's tremendously useful for increasing the reliability of systems and speeding up development time. It just helps to hold the whole robustness story tremendously.

JavaOne Today: You said particularly the realtime people like that.

Gosling: Yeah. Well, because they tend to be even more worried about systems that crash. With a lot of these realtime systems, if the software crashes, an actual person dies. It's a control system for an airplane or a robot arm -- you're just getting ready to stop the arm and you garbage collect and the arm just keeps going because nobody's telling it to stop. And it takes out a wall or innocent passers-by or something. And so you can't tolerate that kind of thing.

And so there was a general consensus that we wanted to have garbage collection in there but we didn't want to live with the hiccups that you get when your average garbage collector kicks in. All garbage collectors have the effect that they tend to shut down the system for some interval of time. And some of them you can actually tune the interval.

Resources