Dr. James Gosling designed the original Java programming language and implemented its original compiler and virtual machine. He is a vice president and Fellow at Sun Microsystems, in addition to being a researcher on software development tools. He also has contributed to the Real-Time Specification for Java. He has a bachelor's degree in computer science from the University of Calgary and a doctorate in computer science from Carnegie-Mellon University in Pittsburgh, Pa.
What is there about Java that most developers don'tbut shouldknow?
Well, the closest thing I can think of that would fit that line is that...the marketing language Sun uses all the time is "Write once, run anywhere." This is remarkably close to truth. One thing that people don't stop to think about is kind of the flip side of that, which is "Learn once, work anywhere." Which has turned out to be a remarkably important thing, especially with people building these large distributed systems that are spread over all kinds of machines, from Solaris boxes to AIX boxes to NT boxes, to cell phones and point of sale terminals, all the way up and down the food chain. The same person could work all over the place, and that gives you both kind of a career-mode mobility within the project. People get to see the whole project. You can actually get a systemic view to what goes on.
So you're saying one of the key strengths of Java is that it is a transparent language, thanks to its architecture?
One of the phrases I like to use is that it gives you a 'homogeneous view of a heterogeneous reality.' This is sort of a way for you to line up in front of you a cell phone, a desktop, and a Big Hunk server, and they all kind of look the same.
Six years ago, what was your vision for what you hoped Java would become? Was this just another project? Did you ever expect this would take on a life of its own?
No expectations of such a life. In fact, at the time that we were rolling it out, I had this discussion with my boss, Eric Schmidt, and he asked me, "So, James, what would you define as success?" I've even got the e-mail somewhere. And my answer was like, "Well, the Tcl guys claim they've got 50,000 people who've written Tcl programs, so that's kind of far out. I think maybe if I could get 10,000 people to try it out and write a program, I'd call it a success." And Eric's answer was, "Boy, I think that'd be pretty tough." We blew by that one really fast.
|My definition of success was pretty modest at the time.
At that point we'd pretty much exhausted ourselves trying all kinds of stuff...and then came this idea of putting it on the Web. On the one hand, you could have strong views about the technical relevance of something and how cool it is, but that's along way from actually working as a business working in the market. So, while on the one hand I had a pretty strong, positive view of the technology, what it takes to get something out there is such a crapshoot. I didn't have any particularly strong hopes that it would do anything really huge. My definition of success was pretty modest at the time.
What were the most difficult hurdles your team had to overcome in order to make it work they way you wanted it to work?
It's not clear it does [work the way it's supposed to work] today.
You don't think it works today the way it should be working?
It's pretty close. You can generate a to-do list a mile long. Early on, there were all kinds of issues, like, so what is our goal, anyway? Very early on, we had a very crystal-clean goal, when we were the Green Project. But then as we went out and turned into the FirstPerson Project, our basic goal was to figure out some way to apply this technology in a business sense, and of course, the first thing we focused on and tried was basically a miserable failure (Java on television). We learned a lot, but there are lots of learning experiences that are not entirely pleasant...we basically learned that cable companies are control freaks, and telephone companies are monopolies that move on sort of geologic time scales. Getting anything done was pretty much impossible.
How much luck was involved in getting all the right nuances into the structure of the language?
I don't think there was much luck involved in that, really. In some sense, the language designed itself. Because if you take this priority list, we came up with this model what we thought would be big issues in the consumer network world. And they were loosely liability, security, culpability...and my piece of the whole puzzle is going, "Gee, there are issues with a lot of these that are right down in the programming language, that are right down in C and C++.
I originally started saying, "Well, why don't I just build this C++ component that would fix these problems?" In some sense, you take the different context, which is for a very highly distributed, consumer-oriented universe, and how does that affect these things? You format with a lot of experience, using every last programming language they've been using for the last 45 years, and the answer is actually pretty obvious. That part didn't require a whole lot of luck.
Where luck came in was that set of issues we identified around it being a distributed consumer networkthat turned out to actually be right. Consumer-oriented networks turned out to be important. Ten years ago, if you had tried to float a business plan around computer-and-consumer-oriented networking, you would have been laughed out of town.