A conversation with James Gosling
The inventor of Java discusses the current state of software
Bill Venners:What have you been up to this past year?
James Gosling:Doing a lot less traveling. I’m not really going around preaching the gospel anymore. Folks are pretty converted these days. I hardly give talks at all now. I’ve almost exclusively switched over to doing long Q&A sessions where I get up on a stage and either people ask me questions directly, or I pull questions out of a fishbowl. For the last year I’ve been working at Sun Labs and ignoring all the usual corporate ‘goo’ that comes with working at a company.
I’ve mostly been working on developer tools. I took a little hacking vacation earlier this year to do a relatively sophisticated Web server. It’s just a pile of JavaServer Pages that manage the labs and the corporate document archive. And that has mushroomed features like mad. But my real job has been developing tools. In particular, I’m interested in tools for people who have to write code.
Most developer tools try to shield you from actually writing code in constructing the GUI bits or the database bits. Yet when you do write code you usually get glass teletypes where high tech is keyword coloring. Really high tech gives you a bit of help as you’re typing in names, but that’s where it ends.
So my work lately has centered on refactoring ideas, where you view a program as an algebraic structure, and you start doing essentially algebraic transformations on the program. That’s been a lot of fun.
Venners:You mean algebraic transformations in the context of refactoring your program?
Gosling:Yeah. One thing my tool will do right now is let you rename a class. Renaming a class at one level is really easy; you just change the name. But how do you change all the references to that class and all the imports? And what about renaming when it includes moving a class from one package to another? I did all this stuff to rederive all the import lists in order to deal with the various naming issues. But it’s going even further. This is prototype number three, or maybe number four.
Venners:Will this tool be seen outside of Sun?
Gosling:Yes. If it gets to the state where it looks like it might have even a vague chance of being interesting. My hope is to throw it over the wall some day.
The complexity challenge
Venners:In several recent interviews, you claim that the main challenge for programmers is complexity. Can you elaborate?
Gosling:In some sense, that’s what this tool I am building is all about. How do you write a complex application? How do you deal with an application that’s a million lines long? How do you even come close to understanding it? How do you make a change to a system like that? How can you cope with it?
Another axis of complexity exists as you lay the application out on a network. One of the things that Java is good at is giving you this homogeneous view of a reality that’s usually very heterogeneous. One of the things going gangbusters recently is the cell phone business. The last time I heard a number, it was like 60,000 Java cell phones were being shipped every day. The numbers have become staggering. And that’s not the highest volume Java platform. The highest is actually smart cards, and that’s a really big number, although I don’t know the exact number.
People building these applications that span the network from edge to center to edge, where you have part of the application in whatever the edge device is — whether it’s desktop or cell phone or PDA — some bits and pieces in the infrastructure, and some bits and pieces in the back ends and the databases. One person can work from end to end, but how do you manage the complexity of that?
We don’t have really good ways to deal with that issue. We just barely have tools that let us look at what one system is doing and map that across an end-to-end architecture. There are people who have these embedded debuggers for dealing with things like J2ME devices. How do you debug code that’s inside your Oracle database? How do you look at the whole thing in totality? That’s the hard and interesting problem. The systems being built get more and more complicated every day.
I spent a lot of time a couple of years ago on the whole real-time effort. The motivation for that came entirely from the real-time community. The main issue was that programmers are not writing a few thousand lines of assembly code anymore. These systems are getting really huge. And Java has proven to be pretty successful in building large reliable systems.
Venners:I’m glad I asked that question because I thought you might have been talking more about the complexity of large, monolithic programs.
Gosling:Yes, even isolated things. Some of these isolated applications that sit on one machine are a million lines of code. How do you deal with that? Most people have no way to wrap their head around it. There are all kinds of tools available, from organizational tool you get from object-oriented methodology, to some of the tools that are based on that, like UML modeling.
But of course the more tools you build to cope with such complexity, the more complex things become. We always strain at the limits of our ability to comprehend the artifacts we construct — and that’s true for software and for skyscrapers.
Venners:Increasing complexity is also being driven by hardware that’s getting cheaper and more powerful.
Gosling:Absolutely. One of my favorite lines is that computers are driven by Moore’s Law, which is an exponential process, and human beings are driven by Darwinism.
Venners:And that’s a linear process or what? Gosling:One way to look at it is as a Monte Carlo process. In Monte Carlo algorithms, the precision of the result doubles as you double the amount of time. So you’re getting better on a square root kind of a curve, whereas computers are going on a two-to-the-N kind of curve. Their curvature points in opposite directions. How do people with skulls of a limited size deal with that?
The role of simplicity
Venners:The opposite of complexity is simplicity. I have often heard you describe your philosophy when designing Java in the early days: you didn’t put something in Java unless five people screamed at you and demanded it. In one interview, you told this really good story about moving to a new apartment and something about keeping things in boxes.
Gosling:That’s actually a general principle for life that works really well. When you move to a new apartment, don’t unpack. Just sort of move in, and as you need things, pull them out of the boxes. After you’ve been in the apartment for a couple of months, take the boxes — don’t even open them — and just leave what’s in there and throw them out.
Venners:The ‘don’t even open them’ part is important because it’s very hard to throw things away once you know what they are.
Gosling: Right, because if you open them, you say, ‘oh, I can’t part with that.’
Venners:So would you say that simplicity is a general philosophy programmers should always have when designing programs?
Gosling:I think in any kind of design, you must drive for simplicity all the time. If you don’t, complexity will nail you. Dealing with complexity is hard enough.
In programming language design, one of the standard problems is that the language grows so complex that nobody can understand it. One of the little experiments I tried was asking people about the rules for unsigned arithmetic in C. It turns out nobody understands how unsigned arithmetic in C works. There are a few obvious things that people understand, but many people don’t understand it.
So one of the most important criteria for judging a design for me is the manual. Is the manual out of control, or is it reasonably concise? You can write a pretty decent Java manual in less than 100 pages. The current Java language spec is pretty thick, but that’s because it’s probably the most detailed language spec ever written. It goes through all of the details. I couldn’t write the Java language spec.
A delegation-only language
Venners:When asked what you might do differently if you could recreate Java, you’ve said you’ve wondered what it would be like to have a language that just does delegation.
Gosling:Yes.
Venners:And we think you mean maybe throwing out class inheritance, just having interface inheritance and composition. Is that what you mean?
Gosling:In some sense I don’t know what I mean because if I knew what I meant, I would do it. There are various places where people have completed delegation-like things. Plenty of books talk about style and say delegation can be a much healthier way to do things. But specific mechanisms for how you would implement that tend to be problematic. Maybe if I was in the right mood, I’d blow away a year and just try to figure out the answer.
Venners:But by delegation, you do mean this object delegating to that object without it being a subclass?
Gosling:Yes — without an inheritance hierarchy. Rather than subclassing, just use pure interfaces. It’s not so much that class inheritance is particularly bad. It just has problems.
One of the metaphors I like to use for the whole design process is this game you see in arcades, particularly the older ones. If you go to the Santa Cruz Beach Boardwalk, there is this game called Whack-a-Mole. It’s a table with 16 holes, and this little mechanical mole sticks his head out of one of the holes for a second. You whack it with a bat. He pops his head up, and you whack him, and he pops up someplace else.
Engineering design is like playing Whack-a-Mole. You have a problem sticking up over there. You go and whack it, and it goes away. But have you really fixed it, or has it just moved somewhere else? It’s often hard to tell whether you’ve solved the problem or moved the problem. And more often than not, when people say they’ve solved the problem, they’ve just moved the problem. So one of my big issues with things like delegation, although I feel like there’s a right answer in there, is that delegation is going to have its own problems too. But it hasn’t been used as extensively, so does it have more problems?
It’s almost a truism that you never actually find a perfect answer to a problem. You just find the answer that has the least problems.
Inheritance vs. composition
Venners:Given that we have both class and interface inheritance in Java, do you have any guidelines you would recommend to people trying to figure out which one of these they should use? When is it appropriate to use class extension, and what is the trade-off versus interface implementation and composition? Or is that too general of a question?
Gosling:No, it’s not too general of a question. I just wish I had some good rules because it always gets kind of vague for me. I personally tend to use inheritance more often than anything else.
Venners:Inheritance meaning class extension?
Gosling:Class extension. I tend to use classes a lot more than interfaces, and I’m not sure why. I’ll use interfaces for things that need to be really abstract and really clean — something runnable or printable. It’s almost like if the class name ends in a-b-l-e, then maybe it ought to be an interface. That tends to be the way I operate, but I suspect that I don’t use interfaces as much as one probably should. And delegation is something that I do a lot under the sheets. One of the nice things about delegation styles is that the user of the contract can’t tell.
JavaServer Pages vs. servlets
Venners:You said that for several months you’ve been working on the document archive and using JSPs. I was wondering if you have any words of advice for people who are using JSPs, servlets, tag libraries, and so on.
Gosling:Probably the most important thing that whacked me in the face was that with the basic JSP model, you have a Webpage template, and you’re filling in the blanks. I found that there were a number of places where that worked reasonably well; but for the most important things — the most complicated and sophisticated pages — I really only had one. It’s like the whole system revolves around this one Webpage that morphs into just about everything, like the portal page at Excite or Yahoo. The page isn’t a template into which you plug little things because everything is plugged together; everything is computed.
It’s computed on the outside, and you piece together little fragments. If you try to use JSPs for that kind of a page, you’d find it feels like it’s inside out. What you want to do is assemble little fragments by the computing results of database queries, and you have the user’s profile to provide page layouts. For more sophisticated pages, JSPs tend to get in your way. Doing a servlet is much simpler. There’s a lot more mechanism in a JSP to help you and support you. Servlets tend to be simpler in terms of what they provide you, but that simplicity comes with a huge amount of flexibility. My central Webpage quickly devolved into three or four lines, where almost everything is done in one line that invokes one method, and that one method constructs the whole page.
Community design process
Venners:Two years ago, I asked you how the proliferation of network-connected embedded devices was going to change software, and you said, ‘you can’t sit alone in a room anywhere and write software. It’s more of a social thing.’ I’ve recently been involved in the Jini community, defining the process of how standard APIs will be agreed upon. In the very early days of Java, you were the benevolent dictator. And now the Java Community Process is running that show.
Gosling:Right. These days I’m the fly on the wall.
Venners:From your perspective, as the fly on the wall then, is there anything you could relate to us in the Jini community about process? What has worked in the Java Community Process? What hasn’t? What can be improved?
Gosling:One of the most important things is the notion of a reference implementation. The ink isn’t dry on a spec until somebody has built it.
One continuing problem is the tension between having a bunch of engineers in a room designing and the organizations with their political agendas that turn it into this competitive marketing thing that quickly becomes dysfunctional. Generally, if the engineers can just sit down and do their thing, the end result will be higher quality. Then there’s this problem that the word ‘quality’ has a point of view because various industrial concerns tend to look at it and say, ‘well, it’s not perfect for me.’
Venners:I see. I don’t know if it was Ron Goldman and Dick Gabriel, the guys who wrote the first draft of the Jini constitution, or where it came from, but from Jini’s beginning there were two houses. One’s a commercial house, which represents people who have invested real money in the technology. They want to have a voice in its evolution. And the other house is nerds. They simply care about technology — they are the designers in a room. For a spec to be approved, it has to pass both houses. It’s like an experiment to keep an appropriate balance of commercial and technical concerns. I’m not sure how well it will work.
Gosling:It’s pretty hard, but certainly the computer industry is filled with examples of places where the only people in the room were really the politicians, and the bits of technology that came out were really goofy. It’s hard. I wish there was a nice answer, but anytime you have more than one person in the room, politics is everywhere.
Venners:It becomes politics. Even in the room of engineers, you have to deal with personalities.
Gosling:Yes. That’s one of the things they never teach in school, and it ends up being the hardest part of any engineer’s job — the whole interpersonal thing. No matter where you are, you’re dealing with people.
