A Converstion with Java's Creator, James Gosling

First published in JavaWorld, June 1999

---

On Wednesday, May 29, 1999 James Gosling, vice president and Sun fellow at Sun Microsystems and creator of the Java programming language, assessed the state of the Java language and platform in a phone interview with Bill Venners. In the course of the hour-long interview, Gosling discussed the current state of the Java programming language and the changes that are being considered for future versions of the language. Looking back to the Java language's early days, Gosling described the extent to which he had Jini technology in mind when he designed the Java language and the problems the Java platform solves in the enterprise. Gosling touched on those areas that have been a challenge for the Java language in the past and gave his impression of how they will be dealt with in the future.

The creator of the Java language also looked at how software and API development will change in the coming age of networked embedded devices. He explained why Jini technology's agree-on-interfaces approach to getting devices to work together on the network is superior to the traditional agree-on-protocols approach. In closing, Gosling shared his views about when it makes sense for developers to build a tool to solve the general case -- like he did when he invented the Java language -- and when it makes sense to concentrate on solving the specific problem at hand using available tools.

The Evolution of the Java Programming Language

Bill Venners: What has happened since the JavaOne show last spring that you think is significant in the evolution of the Java language?

James Gosling: The Java language itself has pretty much held constant. We've worked really hard to keep it very, very stable. We're being conservative about the Java language.

The kinds of things that have changed [since last year's JavaOne conference] have been implementations of the virtual machines underneath the language to give the language much higher performance, make it much more solid, and make it usable in many more situations. On top of the language we've done a lot of work with APIs. One of the key features of the language is this ability to define new facilities as classes. That's been where the explosion has really been: in all the APIs on top of the Java language itself. One main motivation for being conservative about the Java language and keeping it stable is so that all of this work on APIs that are on top of it doesn't get disturbed. Because that's where the real value is, in the stuff that's on top.

Bill Venners: What kind of changes can we expect to see in the language in the future?

James Gosling: There's a list of things that have been on the table for quite a long time. One of the things we get asked about a lot is type polymorphism, which shows up in C++ as its template maker. Five years ago, when I was trying to figure out the right thing to do as far as developing a new language, there were probably twice as many type polymorphism systems in the world as there were experts in type polymorphism. And nobody thought that anybody else's solution made any sense.

While there was a general feeling that there was something good about type polymorphism, exactly what it should look like was very unclear. There's been a really heated debate on this subject over the last few years. (There's a guy here named Gilad Bracha who's run herd on that debate, and a mailing list on the subject called the Java Genericity mailing list.) At this point we're down to about three proposals for type polymorphism, and it looks like we'll get to some kind of a resolution.

If you go to http://java.sun.com/people/jag/Presentations/COOTS99/index.html, you'll find a set of slides from a talk I gave in San Diego four weeks ago at COOTS 99, the Conference on Object-Oriented Technologies and Systems. In this talk, I go through unanswered questions concerning the Java language, including talking about what changes people have been asking for.

The number one thing people have been asking for is an assertion mechanism. Of course, that [request] is all over the map: There are people who just want a compile-time switch. There are people who think those are the spawn of the devil, and they want something that's more analyzable. Then there are people who want a full-blown Eiffel kind of thing. We're probably going to start up a study group on the Java platform community process. We've been using that process for everything, including language changes. There's already a study group starting up on type polymorphism, and a study group is also probably going to start up on assertions.

Performance and the Java Language

Bill Venners: Now that the Java HotSpot performance engine is released, to what extent is performance solved? Are there areas in which performance still can be improved? What future plans might you have for performance improvements?

James Gosling: Performance is one of those things that you're never done with. There is no system on the planet that is ever finished with performance. But our performance is getting pretty good. Lots of people do benchmarks of server applications, and compared to C and C++, we're basically right in the same ball park.

There is room for performance improvement in the new 2D graphics libraries in the Java 2 platform; these certainly need some tuning. One of the persistent performance problems we've had that has been pretty hard to grapple with involves the demand for features: people keep asking us to put this in and put that in. Look at "Project Swing," for example. "Project Swing" is this UI toolkit that is industrial-strength. It's got everything in there, and that makes it kind of big. And big always turns into a performance problem. So we're working on ways to try to make "Project Swing" faster, trim it down, and give it fewer interdependencies, so that it is fast and nimble.

It's this difficult paradox -- that the more there is, the more there is. In terms of the Java HotSpot performance engine, we've put out the first release of it, but there are more interesting optimization techniques that we would like to try which are not there yet. There are many more tricks in that particular bag, and there's a lot of room for it to grow.

Bill Venners: Can you be more specific?

James Gosling: One of the things that made HotSpot rather difficult is that it's a collection from some fairly large number of PhD theses -- a long esoteric list of dynamic compilation tricks. There were a bunch of things that have an awful lot of value that we decided not to do just to get Hotspot out there.

We do an awful lot of dynamic compilation tricks in the Java HotSpot performance technology now, but there's room to add more. Right now [performance-wise] we are as good as C or C++, often beating them, and it's pretty clear that we can get greater improvement out of it.

Another thing is that when you talk about optimizing something, it's often optimizing with respect to a particular situation. The current Java HotSpot technology release is targeted toward making server applications really fast. The kinds of tuning you do in server applications tend to be different than what you do in other places.

Inspiration for the Interface

Bill Venners: In Java you included multiple inheritance of interface, but left out multiple inheritance of implementation. Were you trying to say anything to designers by making the interface a separate construct? Were you trying to say anything by leaving out multiple inheritance of implementation? How did that come about?

James Gosling: It listened to people from the C++ and Objective-C camps, and I tried to sort out who had the most happy experiences. The Objective-C notion of a pure interface with no implementation seemed to have worked out really well for people. It avoids a lot of the sticky issues such as disambiguation that people get into in C++. It's still kind of messy. It's an area that I don't feel totally happy with.

Bill Venners: In what way?

James Gosling: Another way for doing these things is a technique called delegation. Some ideas in the delegation camp felt good, but I never came up with anything that really worked. I ended up with the interface construct, which felt simple enough to be comprehensible, sophisticated enough to be useful. It also avoided any of the tar pits that the other folks got into.

The Jini Vision

Bill Venners: I heard Java was originally envisioned for embedded devices. To what extent was Java designed with what would eventually come to be called Jini technology in mind? In other words, were you just thinking about embedded devices, or were you thinking about a Jini technology-like world?

James Gosling: Oddly enough, something very much like the Jini technology world was in there from day one. The very early version of the Java language, which was called Oak and ran on the Star Sevens, had a distributed message system in it that was very much like RMI. In fact, even though the original distributed message system got ripped apart when we started doing some of the cable television stuff, there was enough of it still lying around that when the RMI folks went to do RMI, they were able to fit in some of it.

Jini's Footprint

Bill Venners: What is the JDK footprint for Jini technology-enabled devices, and is that going to be a problem for people who are making devices where every tenth of a penny counts toward cost savings?

James Gosling: The Jini technology team has put a lot of effort into making it so that it can handle really teeny devices. To be technology-enabled, a Jini technology device doesn't actually have to have a full-blown Java virtual machine in it. All it has to be able to do is respond to messages over the network. And it has to be able to do a certain amount to identify itself and read class files out of ROM.

Homogeneous Execution Environments

Bill Venners: For mobile code to work, the Java platform needs to provide a homogenous execution environment, no matter where you go. That's been difficult to achieve for applets landing in just a few browsers. Is there something new that's going to help Jini service code see a more homogenous Java platform wherever it goes in all these different kinds of devices?

James Gosling: We really have had very limited problems with homogeneity for people who do tested VMs. The browsers turned into a real serious problem. There was Microsoft on the one hand that was just being evil. And then there was Netscape that ran into all kinds of engineering and financial difficulties. So the Java embedded in browsers was just turning into an unfortunate situation for us.

Bill Venners: But basically Sun developed a bunch of tests, and VM and API implementations that actually go through the tests are more homogeneous?

James Gosling: That story is quite different, certainly, for people who take pieces of Java technology-based code and squirt them around between servers and out to Oracle and the rest.

Bill Venners: Do you envision a solution to the browser problem?

James Gosling: We have a solution in place for Netscape 5.0, which hasn't been released yet. The general structure of the solution we're pursuing, that we like the best, is the Java Plug-in, which has been working out pretty well. What we need to do is make that more robust, deal with some delivery issues, and get it tied into the browsers better. But the basic direction for dealing with the browsers is taking the [Java] Plug-in product and making it industrial-strength.

Picking and Choosing APIs

Bill Venners: People who do embedded devices always seem to have this pressure to make things fit, which gives them the need to pick and choose which APIs they'll support. Is there some way of dealing with this pressure, such as somehow getting them to all have the same set of APIs?

James Gosling: Trying to get them to have the same APIs is why we came up with these API subsets. Some of that has worked, some of it hasn't. Much of what we've been trying to do lately has been to make it so these folks can do dynamic loading of pieces of the APIs that they don't support.

A certain amount of it has been trying to get people in the different industrial segments to get together and agree on what the common things are. But what should the standard APIs be that are available in a toaster? Or in some robot arm controller? They're very different.

Bill Venners: So what about the subsets, like Embedded Java and Personal Java? What's the status of those things then? It sounds like you've recognized that maybe you need to go into each little niche and help those people get together and figure out what APIs they need.

James Gosling: We figured that it was pretty much hopeless for us -- both hopeless and sort of arrogantly presumptuous -- to go into the different industrial segments and tell them what we think the API should be. For example, this is what we think the API should be for the GPS navigation system; this is what the API should be for telescope control; and so on. Those aren't things that we have any expertise in.

[What] we really have an interest in is making sure that the participants in those industries get together and figure it out. One of the things we try to do is facilitate matters where we can. So we might have a person or two who's involved in these efforts, but we certainly don't try to control them or drive them or run them.

How Software Development Will Change

Bill Venners: How will the emerging hardware environment of network-connected embedded devices change the way software and APIs are developed?

James Gosling: I think the biggest difference is that you can't just sit alone in a room and build stuff, because the things you're building interact with everything out there. You can't just sit alone and do whatever you want.

Bill Venners: And why is that?

James Gosling: Because you're trying to interact with other things, you have to know what the other things do. If there are multiple people doing similar kinds of things, they have to have some kind of an agreement on how these things should work. If you're designing an electrical power delivery mechanism, for example, you have to design a wall socket. And everybody has to use the same wall socket; otherwise those toasters won't be able to plug in to you.

It becomes an environment where people have to be much more socially involved. It really is a community thing.

The Idea Behind the Interface

Bill Venners: You once said that the core of object-oriented design is "figuring out what the interfaces are." Could you elaborate on that?

James Gosling: The interfaces are the things that connect the pieces. You've got a toaster and a power plug in the wall; it's the way you connect. The core of the object-oriented design thing is to try to figure out what the interfaces should be. The actual technology of object-oriented design in a programming language is how you express those interfaces.

From a developer's point of view, the art is in figuring out the important things to have in the interface. Actually, the hardest part is figuring out the things you should leave out. Because one of the important aspects to designing interfaces is to make them say just enough so that people who want to use them can use them and do what they need to do -- but not so much that it makes it difficult for people to change things.

Interfaces vs Protocols

Bill Venners: Microsoft claims their Universal Plug and Play (UPnP) is superior to Jini because it uses the time-tested approach of having people come together and define protocols. At the Jini Community Summit last week, Bill Joy said that he's seen how long it takes people to come to agreement on protocols. And he thinks it's easier and faster to agree at the higher level of an interface. Could you compare the two approaches? In particular, why is Jini's agreeing on interfaces approach better than UPnP's a greeing on protocols approach?

James Gosling: The big deal to me is the flexibility that Jini technology gives you. If you look at the phone companies, they offer special features -- like call waiting. It turns out that these special features in the phone system are dependent on all the different switches and components in the infrastructure being built to support particular protocols. So if you want to invent some new thing, as in call waiting, the only way you can get it out there is to go around to everybody and convince them to implement this new protocol. Then, everybody must upgrade every piece of hardware in the entire infrastructure.

The Jini technology story is that up-front you agree on a mechanism for building flexible systems. That allows new behavior to be downloaded into systems. When people invent new things, they don't have to go around convincing people to handle these different protocols. There's a standardized way for people to offer some new behavior for you. And then within the context of security policies, the behavior just sort of gets involved.

One of the reasons that is particularly important is that for standardized protocols that everybody wants, it's possible to get them through the process, even though it's really, really painful . But for specialized things, it just never happens.

Bill Venners: Because of politics?

James Gosling: Yes, because once you've got the standardized protocols, if you want to add some specialized thing, you'll never do it.

Bill Venners: When you say "building in flexibility up-front," are you talking about Jini being able to send the object?

James Gosling: The key thing about an object is that an object is data plus behavior. So when Bill Joy talks about downloading an object, he's talking about downloading behavior as well. When you've got a hand-held remote control and it's talking to some things in your AV system, if you have a standardized protocol, then if somebody invented a new kind of filter function or kind of box, you can't get to it from your remote. Go home and look at the universal remote controls. When DVD players came out, none of the control systems dealt with DVD players. Nobody's home stereos had a connector in the back for a DVD player. And so the whole standardized protocol thing totally failed. And it turns into a real block on innovation.

With something like a hand-held remote control, where the remote control has an LCD screen, the control software gets downloaded to it. If somebody has a DVD player, all it does is, it takes the object that represents its interface and sends it to the remote control. And that interface object can do whatever it wants on the screen, whatever is appropriate for that newly invented device.

Jini technology handles the control parts of the system, but you also need the interconnection part. In the audiovisual world, there's a thing called IEEE1394, sometimes referred to as FireWire. It started out at Apple, and it's now being pretty heavily pushed by Sony. It's a 400 Mbps networking standard for home audiovisual equipment that lets you shift audio and video and control stuff across networks. You put all those pieces together, and you end up with a system that can be incredibly flexible, where people can invent new things that just fit in.

Server vs Service

Bill Venners: Could you elaborate on the distinction between a service and a server?

James Gosling: It's like the difference between an interface and an implementation. When people talk about a naming service, it's -- in the Java world -- an object with an interface that you talk to and say: Here's a name, look it up for me. And whether that turns into pulling something out of a hashtable locally, or sending a network request to a Novell server, or a Sun server, or whatever, is independent of the service interface. It's actually a bad thing for the application developer to know how that request is being satisfied. If you just ask to look up a name and then it gets done somehow or another, it gives you hugely more flexibility in deciding what's where.

The Jini technology folks push this really hard because in the case of a name server, they need to be able to handle some pretty dramatic scaling. They need to be able to have very small name servers that handle two or three devices. And they also need to be able to handle large enterprises with hundreds of thousands of nodes. If you try to span that with one particular technology, you'll just get into trouble. Because there are name-server technologies that work really well at the high end of the scale that are just way too heavyweight at the low end of the scale, and ones that work just fine at the low end of the scale that just run out of steam at the high end.

So, the way you do scaling is you step back from any particular implementation, abstract from what the service is, and then as you run up and down the scaling chart, you switch from one implementation to another.

Bill Venners: And why is it a bad thing for application developers to know about how something's being implemented?

James Gosling: Because as soon as they do that, they get committed to one particular implementation or the other and then all of a sudden the repluggability of different servers becomes more difficult.

The Enterprise Vision

Bill Venners: To what extent did you envision the Java language playing a role in the enterprise when you first developed it?

James Gosling: Not at all. It was a funny thing where very early on the view was that there was this established technology base that was pretty much impenetrable. Even though there were problems, market forces meant it was essentially impossible to break into the enterprise. So we decided to focus on areas where things weren't as tied up, which is partly where the consumer-electronics thing came in. We focused on that area because it seemed to be the most open one.

But when I designed the whole Java technology system, it came with years of experience doing all kinds of systems. And the reaction of enterprise folks, when they looked at the Java technology system, was, "Wow, this solves a whole bunch of my problems!" But early on getting into the enterprise certainly wasn't a goal.

Bill Venners: So given that it was more perceived along the lines of embedded devices, or that's how you thought of it, would you say there's deficiencies in Java for the Enterprise environment, or areas where you could do better at the language level?

James Gosling: I guess I've done these embedded languages for a very long time. And one of the lessons that kept getting beaten into me over and over again is that when you design a system, you have some kind of a model of what people are going to do with it. And so you tend to build for that model. But every time I've done that, it's just been miserable, because people have always taken the system and done things that I never, ever expected. So when I designed the Java language, in many ways it was grotesquely overdesigned for its target.

Bill Venners: As a result of learning the hard way that people like to use things in ways you never imagined?

James Gosling: People always want to scale them up in amazing ways. And so I decided that this time around, rather than trying to focus on the particular application area, I was going to do a full-blown general-purpose thing.

Java Language Development in the Enterprise

Bill Venners: How well does Java technology scale to, say, one hundred developers in single enterprise who are all banging out code?

James Gosling: It actually scales pretty well. There are a number of things that make that work. The central thing is the whole object-oriented philosophy, this business of building systems out of modular parts. And the modularity of systems in the Java language is taken very seriously compared to other systems. You really can't build a nonmodular system in the Java language. The interfaces between modules are very strict -- you can't get around them. They're really like a contract.

So the different parties have a really clear understanding of what each is responsible for. This helps teams work together because there's a clear understanding of what the rules and responsibilities are of team members. And as each individual team member knows what he or she is doing, you don't get this problem where people have their fingers in code all over the place.

Enterprise Problems Solved by Java Technology

Bill Venners: You said you designed Java in a general way and then people on the Enterprise arena came along and said this solves a lot of my problems. What kind of problems does the Java language solve for the enterprise?

James Gosling: It's a long list. I think probably the biggest ones are a lot like the stuff I've been talking about: the modularity, making things so that you can do modules that really work properly. In C++, there's been this problem that's often been called the fragile base class problem: If somebody defines a class and somebody else does a subclass, when the first person changes the base class, you have to recompile the subclass.

Also, in the Java language there's nothing you can do to cause memory to get corrupted. There are years and years of statistics on where the energy goes in maintaining large pieces of software. And, historically, over 50 percent of the hours that people have spent tracking down bugs have turned out to be due to some flavor of memory corruption. With the way that pointers and arrays are in the Java language, essentially all of those go away.

Bill Venners: It sounds like the Java programming language addresses a lot of productivity issues, then, for the enterprise.

James Gosling: Yes, and productivity is not just the productivity of developers; it's also the reliability of the thing they produce. Reliability and productivity are linked. Because the less time you spend debugging something, the less often something crashes when it's out there in the field, and the more productive your developers are.

To Tool or Not To Tool

Bill Venners: I heard that when you went off to the Green project, you started writing the software in C++, and then you later decided to make a new language. There are times when I've felt the urge to develop a tool to solve a problem as opposed to solving the problem itself. Could you say a few words about when it makes sense for developers to develop a tool to solve a general case, as opposed to solving the specific problem in front of them?

James Gosling: That's a deeply unknowable question, because it's not like there's some little scientific formula that sort of says: If you're feeling more than 27 ounces of pain, then build a tool. It's really easy to get started off in this path of building tools, and then you never actually do the thing you set out to do; you just build tools.

In a sick sense, that's basically the story of my whole career. I set out to do things, and I always end up building the tools. And then the actual thing kind of gets lost. And there's no real answer other than having been there many times and getting kind of a feeling.

Tools in general make sense when there are repetitive things that they can help you with. Programming languages are a really dubious thing to create. I've done a lot of them, and they can be really good solutions to all kinds of problems. But they come with a learning curve infrastructure problem that can make them pretty difficult. And, actually, in the Green project I wasn't real happy about going off and doing a new language. It started out with me not trying to do a new language, but trying to fix some underlying issues in C++ that were not so much C++ the language, but C++ the compiler.

The Java programming language has things about architecture-neutral executions, for instance, and dealing with the fragile base-class problem. You can actually solve those problems within the context of C++. I mean, it's just sort of an artifact of the way the C++ compilers are built that they have this problem. My original goal was to build a C++ compiler that didn't have these problems. But then as I worked on that, and as the developers on the project sort of came after me, it became really clear that there were other problems that needed solving, and it sort of evolved into just a new language.

This article was first published under the name James Gosling looks back at the Java language's past and forward to its future in JavaWorld, a division of Web Publishing, Inc., June 1999.

Talk back!

Have an opinion? Be the first to post a comment about this article.

About the author

Bill Venners has been writing software professionally for 14 years. Based in Silicon Valley, he provides software consulting and training services and maintains a Web site for Java and Jini developers, artima.com. He is author of the book: Inside the Java Virtual Machine, published by McGraw-Hill.