Keynote Panel:

Eric Schmidt , Vinton Cerf, et al.

April 2, 1997

John Gage: Thanks very much. Well, we've jammed everybody in-there are still a few seats available. I'm glad you're back. We have 90 minutes, and we're going to use it as densely as we can to explore the past, present and future of the Internet; past, present, and future of Java; what the impact of Java is on the Internet; and how the two mesh.

To lead us through that, let me introduce Sun ^TM employee #92; still a Sun employee; still the Chief Technical Officer of Sun. Now with this Novell business, somebody said, ``Does this mean that Sun is losing its Chief Technical Officer? We said, ``Well, we don't view it that way. We view Eric Schmidt's shift to Novell as a gain of 60-million desktops. '' [applause and cheers from audience] That's how we view this. The numbers are 4-million servers, a million servers shipping each year. Eric Schmidt, come tell us about it.

E. Schmidt: Thank you very much. It's unusual -- normally when you take a new job, they say `` sayonara,'' but Sun is not that kind of place. Sun is a different kind of place, and I want to thank Scott, and Alan, and George, and the team for letting me participate today in my last act as a Sun employee. I will certainly miss working for Sun. For those of you who have not had an opportunity to work for Sun, it's a wonderful place.

What I would like to do is talk about time, because time seems to drive almost everything. I've been studying this. Time was first measured on sundials in the year 1500 BC. Now you wonder how they knew it was BC? But, nevertheless, it took them about 2,000 years and they figured out how to put the little lines on the sundial. Then one day, somebody happened to move a sundial on the earth, and they noticed that the time changed, and all of a sudden, time was understood to be related to where you were on the earth.

Later on, clocks were invented, and the primary thing that drove the development of clocks in the 13th, 14th century, was this very big concern, if you were a marine person, that you were going to sail off the edge of the earth. For various navigational reasons, you could figure out where you were in this dimension, but if you went west far enough you couldn't except with some knowledge of time. So again, the relationship of time and distance covers everything. Messenger systems, right? The notion of store and forward networks has been with us for 4,000 years, and semaphores were used in the year 1793 to do something similar. So we've had a long, long history of time, and information, and motion, driving our civilization.

Today, Sun sells systems to large enterprises, who install those systems to get efficiencies in the way their businesses operate. It's called ``enterprise resource planning.'' Those efficiencies are worth hundreds of millions of dollars to those customers, all because of time.

What's happening now is that time is changing again because of the Net. It used to be that you had this enormous gap-you might have two different groups of people in different parts of the world who would invent things, but they wouldn't discover each other for six months. Now that sort of thing doesn't happen. Now, the delays are measured in milliseconds. The distance between here and New York is 25 milliseconds, or 3,000 miles. You think of it as contemporaneous, but it really isn't.

Time compression all around us seems to be the thing that's driving globalization. And globalization in our world is the thing that's driving economics, and politics, and people, and so forth. So it's all ultimately based on this issue of time.

The Web is our metaphor, right? It's our space where we can see this. I mean, here we have the most significant development along with the transistor. Paul Baron, who wrote some of the early papers, along with some other folks, did this in 1962. But we've built this first phase, and now we're entering a second phase of the Web -- one around commerce. This drives an opportunity for new protocols around commerce, new strategies for global domination. You can imagine a group doing one protocol, another group doing another protocol, and then a group in the middle does protocol arbitrage, and makes money.

The Internet is such a phenomenon that I think of it as the first thing humanity has built that humanity does not understand -- a frightening concept; one of the largest experiments in anarchy -- the largest experiment in anarchy we've ever had. And this platform that we've built, is a platform for differentiation and uniqueness.

So far, folks who have looked at the Net have said, `` Yeah, yeah, everybody's getting connected, everybody's having a good time.'' But every one of these new opportunities is really an inversion of the way we do business. We should expect as we enter the second phase that everything we learned in the last two years, that we got so incredibly excited about-HTML, the Web, Java, all that -now makes sense. Right?

But, it changes again. And it changes in some very interesting ways. For example, look at browsing, a classic example. There's been a study that says that people who spend a lot of time browsing at home watch less television -- 21% less television on average. But it doesn't make any sense to me. When I browse, the Net is so slow I have to watch television. I mean, this notion is wrong, this is a return to time-sharing. I did that 20 years ago.

The right model is that the information comes to me. PUSH is an example of this. There are many other ways. But the important thing is that in a world, which is bandwidth-constrained, or economics-constrained -- economists are now trying to figure it all out because Internet economics are still rather unusual. Now all of a sudden, we have this opportunity to build a new model where the information comes to you.

Here's another example in this diagram. [refers to slide ] We just learned in the last 12 months that we have an Internet, we have a firewall, and we have the intranet. The intranet is where the good guys are -- the Internet is where the bad guys are, and the firewall keeps them all out, right? Everybody knows that -- huge growth business! But obviously not the right model.

Shouldn't the right model be that the nets are all interposed together, using encryption and other security that scales together? Doesn't that make more sense? In fact, the inversion that will occur is where the nets lay on top of each other, and you use encryption and other security aspects to make that happen. Each of these inversions-and I've given you two examples-will spawn a market of billions of dollars in the next couple of years, for all of us to participate in.

Finally, technology is also changing the way we see this, because this is a technology that is leading us to a person-centric world. I call it ``the world of me.'' I don't mean me personally. I mean, the ``world of the person,'' what the person wants, how the person thinks. We've never had a medium quite like this. All the previous mediums -whether we like them or not, whether we support them or not -ended up concentrating the power of information in a relatively small set of people and institutions. This new model is a very different model.

Again, I've concluded that it's all about time. There's this enormous desire people have for intrinsic recognition. And the power of me allows you to do that. I have to tell you an aside. I have a 12-year old daughter who early this year fell in love with a rock group called `` Oasis.'' And if you don't know who they are, they don't sound any better on the Internet.

Of course, we have a web site at home, and so she constructed her web page, and wrote everything there is to know about Noel, and Patsy, and Liam, and all the things that they do. Trust me, you can visit the page if you're interested.

So she posted her page and she comes home every day from school and she checks. And I ask, ``What are you doing? '' I had explained to her how these search engines find you. Every day she'd come back, but it didn't find her page for two weeks, and this became the biggest crisis that she's ever had. She's only 12.

One day she pages me. I say, ``Hello, Allison, what's going on? Is the house on fire?'' ``No,'' she answered, `` It found me!'' It turns out she'd wired it; she'd forced it. So okay, good -- two hours later; she pages me again. ``Hm. Is the house on fire now?'' I ask. ``No,'' she said, ``I have a problem.'' `` What's the problem?'' Apparently, she had posted a quiz concerning the goings-on of the Oasis rock group. These people are 23-years old. They're very..., well, trust me.... She had posted all sorts of quizz questions about these people. Three people had answered the quiz correctly in two hours and she had promised a prize. And I said, ``But Allison, you're a kid. You don't have any assets. You didn't think about this.'' So I left her to think about it, and she decided that she would list their names on her page. Huh? This is all very interesting, and it all centers around intrinsic recognition .

Last summer I was corresponding with somebody who's -- terrible story, terrible, terrible story -- his employer had taken his SPARCstation^TM away from him. [audience groans] And I felt very, very badly about this, and so I sent him one. Okay, hang on, hang on. He was only 12. So Danny, that's his name, sent me -- and he's in the audience -- Danny sent me a note a couple weeks ago, giving me all the things that happened. Apparently he was out playing basketball when his SPARCstation showed up at his home. So he gets his home wired and so forth, and he uses all sorts of free software.

I told him about my daughter, and so they corresponded. I go home and she goes, ``Yeah, yeah, I've been talking to this guy all day.'' I said, ``What's it like? '' She said, ``Well, he found all sorts of bugs in my HTML page.'' I said, `` What is this, a prelude for dating?''

This is a very new thing. This is a very big deal. I talked to a group at Berkeley and I asked the Berkeley students, ``Are you all the most connected people in the world?'' And they said, ``No.'' Having been a graduate student there I assumed the answer to such a question would have been, ``yes.'' But they said, ``Well, we grew up with computers, but the generation that's coming up behind us is growing up with networks. ''

I don't think people of my generation understand this. And it's all around this notion of intrinsic recognition. So in this new model, this ``world of me,'' the biggest challenge is going to be getting people's attention, and that will be our challenge as we all go forward.

I was very worried as we built this world, that the latency of the network would become extreme, because, for various technical reasons, the structures didn't make a lot of sense. But, it looks as if, in fact, we've got a good report. A few months ago it appeared -- as you can see on the left-hand side of the screen there [points to statistical illustration on the screen] -- we had a structure where there were a number of top-tier players, and all the second-tier players -- who wants to be called a second-tier player -- had to route through the first tier. Well, it looks like that's not actually occurring. In fact, we're building a web, a true web, where, in the future, it looks like protocols will not be going through any particularly centralized points. If this occurs, and I believe it will, then we are, with this mixed tier-model, building a digital communication system that is largely unregulated for the world; that is going to end up being extremely reliable, though it came out of the most unreliable components. Who would have thought 20 or 25 years ago that the outcome of all this packet switching would be a structure that attacks the entire model that we have going forward?

If you follow that line of reasoning, then you can see that a new kind of business is being created, and that business is what I call an ``information utility.'' We don't have these yet but you can see that they're coming, and Sun would be properly viewed as an ``information utility equipment supplier. '' And that supplier sits right in the middle: working with content, working with the broadcasters, working with the people who make the networks work in order to get the information to you -- to get the caches filled. This is the next great industry that will be spawned by the revolution that we have built collectively over the last 30 years. So where are we?

We're actually at the beginning of a new architectural transition that changes everything again because of time, because of the models of computing that we've defined, and because of what we're all doing. All of the existing models of computing that we've grown up with in the last few years are derived from time-sharing models of the 1970s. There's an opportunity now for a very different model -- let's call it ``Java Computing,'' and that's the right name -- and it's a model where you go from relatively flat networks, big clients and servers, and static applications to a relatively large number of, relatively centralized servers, and an architecture that anticipates billions of mobile client devices.

Look around here in the Valley. You'll find start-up after start-up after start-up, figuring out ways of using spread-spectrum wireless, and other kinds of technologies to give you the kind of bandwidth you need, so that when you walk around, you'll have the same kind of connectedness that you have when you're fixed.

In this model, these systems have radical ease of use that are selfconfiguring. They're completely trusted and safe. It erases the intranet and Internet division that we all accept today as given by God. And it's net and device-independent. That new model is, in fact, the business opportunity -- the technology opportunity -- for all of us. Thank heaven the Internet happened, that Java happened, and that this new cycle of reinvention occuring in our industry has been enabled.

So with that, thank you very much.

I'd like to move to our next segment now, and give you just a paragraph or two on the history of how we got here. I'd like to begin with ARPA, the Advanced Research Projects Agency, which started in January 1958. Packet switching -- think of it as distributed networking -- was originally described in 1962 by a fellow named Paul Baron. He, of course, was doing it back during the Cold War in the context of building survival networks in case of nuclear attack. And there's a fellow named Donald Davies who invented and described, roughly in parallel, the same concepts.

A fellow named Bob Taylor, who went on to work at Xerox Park, was the manager of the lab that invented almost all of the computing concepts of the PC revolution and the networking revolution. In 1966, he hired a fellow named Larry Roberts, and in 1967 Larry defined the concept of an ARPANET. Also in 1967, something called the ``interface message processor '' was invented, and this product is the forerunner of today's routers -- not really a router, but kind of like that -- and the first four of those nodes were built at UCLA, SRI, University of Utah, and University of Santa Barbara.

That sequence of events has been brilliantly chronicled in a book entitled Where Wizards Stay up Late by Katie Hafner and Matthew Lyon. If you can't get it here, you can get it from Amazon.com, and I'm going to use some of Katie's work to go through this.

We have with us four of the principals who initially made the ARPANET, and later the NSFNET, happen. And we're going to have a discussion with them. We have Vint Cerf, who, I think is well known to everyone here, is currently at MCI. And we have Bob Kahn, who is the president of CNRI. Vint and Bob wrote the seminal paper that described TCP.

We have Steve Wolff from the Department of Defense, who was originally at the Army Research Labs -- he drove much of the NSFNET's creation. And we have Hans-Werner Braun, who was the chief architect of that. What I'd like to do is join them, and see if we can get some discussions going about this whole area.

Vint, you have your suit and your PC!

V. Cerf: I'm sartorially and politically correct. That's all.

E. Schmidt: Now I have to ask Vint a question. In 1994 you were named ``one of the most intriguing people '' in People Magazine.

V. Cerf: Yes, this is true.

E. Schmidt: It was you and Lady Diana and O.J. Simpson, I believe. Your wife, Sigrid -- what did Sigrid think? [ laughter]

V. Cerf: Now, wait a minute, this was not a menage à trois, I can tell you that! [laughter] I think that it added a lot of spice to our married life -- having this ``intriguing person'' crawling around the house! ``Who the hell are you?'' But a more powerful thing to do, frankly, is, if you're bearded, shave your beard off. If you're married, your wife will think you're somebody else, and it does wonders for your love life. [laughter]

E. Schmidt: Write that down! [laughter] Bob, you were actually the person who drove the creation of the ARPANET. You worked at BB&N. Can you describe what it was like in 1967 and 1968? Was it basically a bunch of engineers sitting around thinking it was all obvious? I mean, how hard was this?

B. Kahn: We didn't think it was hard, so much as it was challenging and exciting, sort of the way you probably feel about Java computing today. It was the world of the future unfolding in front of us, and I think we felt very confident that it could just be built and it would work. And in fact, we built it, and the very first packet that went out over the Net got through, as did almost all the others behind it. [laughter]

E. Schmidt: When I think about you, and it's a great honor for me to be here with four of my personal heroes, I think of you as the person who made openness happen -- ``Mr. Open!'' It was your idea that things would be written down and that you would have people collaborate in an open model. How did that come about?

B. Kahn: You have to remember the ARPANET was commissioned out of defense. I had been on leave from MIT working at a small company in Boston, in the Cambridge area, called Bolt, Beranek & Newman, which, at that time had very little experience in the networking business; in fact, none.

The whole model that I think ARPA had, and certainly BB&N had at that time is that the ARPANET would take over the world. Many people have had similar ideas since then, but it was all going to be a centrally controlled thing with ARPANET nodes everywhere.

But, I just felt that, number one, that model couldn't sustain itself in the long term. And number two, we saw, on the horizon, the possibility of other kinds of network capabilities. I was in the business of trying to develop a first packet satellite net on Intel SAT 4 back in the early 1970s. We successfully built, and I designed, the very first ground packet radio system that used the CDMA technology now becoming so pervasive. Here were three very different nets and the question was, ``Can we figure out how to make them work together,'' because they were all very different.

So we ended up in a world where, instead of one organization creating the technology to embed all these other networks invisibly inside, we had interfaces that defined global addressing. Vint and I collaborated on the TCP/IP protocol suite to define, essentially, an open-architectural model in which other networks could federate. I believe the key idea there was one of open-architecture networking.

E. Schmidt: At the time you were facing a legal monopoly, AT&T, that had a very different model for how data was going to be exchanged. Can you talk about that?

B. Kahn: You could say that now.

E. Schmidt: You could say that in retrospect. Did you consider other models besides using 56-kilobit lines? Did it occur to you to try some other approach?

B. Kahn: You have to remember there were many people involved in thinking this through, and the original model was to use the dial-up telephone lines. So then we had the situation if a computer wanted to talk to another one, just dial it up, ship the data, and if you wanted to, you could go to a third place that could maybe ship it, and relay it for you. That was really the model until people began to worry about the delays of setting up connections, errors on the telephone lines, and the very low speeds that we had in those days. A one and a half megabit seems low today in the wake of OC48 optical systems, but back in those days 300 baud was a lot of bandwidth.

The idea of linking it up with telephone lines somehow did not hack it. So the idea was born that maybe we should go to really high speed nets, which in those days were 50-kilobits per second, and link them through these little minicomputers -- a concept that Wes Clarke introduced -- and somehow keep all of those lines hot all the time, but instead of having them in a ring, maybe have some cross circuits between them and let these little minicomputers make all the decisions about routing. And thus was born the concept of the ARPANET as the pioneering packet-switching network in the world.

V. Cerf: It might be important to remember that at the time this was going on, all there were were time-shared machines for all practical purposes -- you know, KL10 type things, and so you didn't have microprocessors or laptops, or anything like that. We had no workstations. We just had large shared machines. So time-sharing was the normal mode in the late 1960s and early 1970s when all this was happening. So interactive access -- remote access -- was an important theme. We didn't get to the large numbers of machines that were kind of running in parallel, and in equal partnership until a bit later.

B. Kahn: The question I'm asked probably more than anybody else is, ``Did we envision what was going to happen in the future when we were doing the original work on the Internet? '' And to answer that I'd say, ``We would have had to envision the breakout of AT&T. We'd have had to envision the creation of a whole workstation and local area network capability -- witness Sun and Cisco as two of the examples. We would have had to envision the transfer of the responsibility from ARPA, under the Defense Department, to the NSFNET with a much more broad-based notion.'' Steve was at the National Science Foundation (NFS) at the time when that rapid expansion took place. ``And then we would have had to envision the decision by the U.S. Congress to allow the NSF to let this whole thing commercialize, since only government money had principally gone into creating it in the first place. None of that was really possible to do in the early days.''

E. Schmidt: When did you come to understand that you were doing something that would probably get the four of you in the Smithsonian Institution -- posthumously, I suspect!

B. Kahn: We've been in the Smithsonian before.

E. Schmidt:, Statues -- right? Vint is quoted in Katie's book as saying that it occurred to him in 1989, when you were at the Interop Show, Dan's Interop Show...

V. Cerf: Right.

E. Schmidt: You said that it was an epiphany to walk into Interop Show and see the major money being spent on exhibitions with huge demonstrations set up -- Witness Java. You said, ``I realized, oh my God, people are spending serious money on this. We started looking at network statistics and realized that we had a rocket on our hands.'' And you later said that standards should be discovered, not decreed, which I particularly like. When did you understand that you were doing something for humanity?

V. Cerf: Well, I don't know yet whether we've done something for humanity. I get email, in fact, if we can switch to my output for just one second, I'll illustrate what I mean by that. What you're seeing here [referring to slide] is a fast calculation that Fred Briggs, the Chief Technology Officer at MCI and I did. Back in 1996 in January, we were consuming 1% of all of our fiber backbone for our Internet services and the other 99% went for voice services. Voice services are growing at 5-10% a year, so we projected out the Internet growth rate, which traffic-wise is about 300-500% a year.

So by April of the year 2000, our Internet backbone will have to consume as much capacity in the fiber backbone as the voice network does. So we tried to project what the outcome and implications of that would be.

This is the prediction that we ended up with: by the year 2010, 100% of all traffic will be packetized. I'm sure you'll be pleased to know that. We also predicted that none of it will be voice. There's a reason for that. The reason is that we will stop talking to each other, because we'll be mad at each other from sending flaming email. [Laughter and applause ]

I actually get email from people who have been very positively affected by the influence of being in the Internet environment, but I also get mail from people who are very concerned about the exposure of content to kids and things like that. So it's a mixed bag and, not surprisingly it's a cross-section of the world.

E. Schmidt: When the two of you became the hottest team in technology, how did it become clear that this was a big problem to be solved? I'm referring now to the invention of TCP, which is what I think you'll both be known for ultimately, and the spreading of that technology around the world. How did it come about? Were you just sitting at a bar one day?

B. Kahn: Well, I think Vint and I brought two very disparate points of view to the creation of that protocol. Vint had been very involved in the first host protocol for the ARPA net. It was called NCP at the time. And I remember when that happened. It was happening in a different group than I was in, because we were building the network itself, the packet-switching subnet.

And I remember taking a look at the NCP protocol when it was first laid out, and I didn't think it was a very good thing at all, but didn't know enough about the host machines to figure out how to do a better job. I just knew that wasn't going to be it, because in order to send something you had to wait for an acknowledgment to come back. And I knew as speeds went up and distances increased, that meant that the rate at which you could send messages would go down, eventually to zero. So we needed something different.

And when the packet-radio technology showed up, it basically attacked a fundamental principle of the ARPANET, which was that nothing got lost in the ARPAMET. The ARPANET was viewed by people connecting to it as a perfect device -- plug something in, and it would work like a line printer. If your messages didn't get through, you simply pressed the restart button. Well, in a radio environment you can have hills that get in the way, people can jam your signals, a lot of things can happen to mess it up, and you fundamentally needed a set of protocols that would enable that problem to be taken care of. Thus automatic retransmission and the like.

And then we needed to deal with the problem of global addressing, because with multiple networks, it wasn't sufficient to say, ``Put it out that port on the ARPANET'' because all it was doing is going into another net, which needed more instructions about routing. So we needed a global addressing space.

That's what got me into the issues of designing the networking piece. And Vint, of course, had the key to plugging into the operating systems. And when we sort of shared those two notions back and forth, it became clear that by banding both our experiences together, we would end up with a better design than either of us would have done all by ourselves. And so it came out of that collaboration in the spring and summer of 1973.

E. Schmidt: The interesting thing about TCP, and later TCP/IP, is that you created with your work, the modern notion of an internetwork, and ARPANET continued for a while, and then all of a sudden, there were all these other interesting networks. And that's where I'd like to bring in, some of our NSF network people. Let me introduce Steve Wolff, who I've known for a long time, and I think is the person who pioneered, more than anyone here in this room, the notion of letting a thousand flowers bloom.

What he did, and did so skillfully at NSF, was that he put a little money here, and a little money there; and he found a bright person here, and a bright person there. In addition, he found a way to leverage what was then a relatively small amount of money to create the next wave through the universities, and through the collaboration that then created the accelerator that then created the opportunity for commercialization. Is that roughly correct? And was this difficult for you politically since you were a government employee?

S. Wolff: Eric, you're making a virtue out of necessity. NSF is one of those organizations that, like universities, never has enough money. So it's always forced to try to improvise.

E. Schmidt: Did you understand that you were, in fact, creating the first Internet service providers? Did you understand that you were creating the regional structure that we've grown up today? Or did it just sort of happen?

S. Wolff: Those are two different things. The regionals were again a way to get the job done without spending too much money, and making the universities pay for it themselves. Internet service providers, of course, started out long before the NSF ever got interested in the business. Rick Adams and UUNet was basically the first Internet service provider. Those of you who remember the early days of email with all the strange addressing structures; remember if you got a piece of email and you didn't know what to do it, the answer was fling it at Seismo, right? Give it to Rick Adams and he would know what to do with it. So he was the first real Internet service provider. After that, PSI came along, of course ANS and then a thousand flowers did, in fact, bloom.

E. Schmidt: Did you anticipate the commercialization that would occur later, or was it, initially, simply an NSF research university project?

S. Wolff: Commercialization was always intended. And the reason is the same one: money. It was clear that the university community couldn't afford this fancy packet-switching network that would do all the wonderful things. The only way that they could ever afford it would be if they were just an appendage of a much larger commercial enterprise. Can you imagine the universities having their own telephone system, or their own package delivery system? It just doesn't work that way.

B. Kahn: In fact, the thing that I find so compelling about what Steve did with his colleagues at NSF, is not to understand that it had to be commercialized -- because it's the only way to get scale in spreading -- it was figuring out a way to actually get there. That's the wonderful thing that you guys did.

H. Braun: In terms of NSF seeding those activities, one additional issue that sometimes I'm still reminded of, is that your budget in your early years was about roughly comparable to the budget that the University of Michigan had for just the campus paper, and you were supposed to create a national network out of it.

S. Wolff: Yeah.

E. Schmidt: And he did, somehow. Now, Hans-Werner you were actually part of a project that was called the Merit Project, which again is part of the network that ultimately became the Internet. But Merit was actually focused on X25. How did it become a TCP/IP base, and how did all that transition?

H. Braun: When I first started to work at this, it was actually a spare-time project, because now it was a statewide network within the state of Michigan and very much focused on its proprietary protocols as well as on X25. In those years, in the first half of the 1980s, it seemed, to me at least, that TCP/IP was pretty much a research project and on its way out with people actually using X25, and GOSS (government open systems specification) being pretty much the thing to do.

I found it extremely gutsy of people like Dennis Jennings, who initiated it, and Steve Wolff, of the government, who then stuck with it against the GOSS mandate, by actually going with TCP/IP, and leveraging off the great work, the great research and development, and prototyping work that had been done at ARPA with Vint and Bob, and other people, and really moving it from research to a reality. They took it from research to a real operational infrastructure that, was, in the end, broadly accepted, and created, or helped create at least, these commercial activities that you see today.

S. Wolff: There were a couple of reasons, really. There was a theoretical reason in that competing protocols were either proprietary, like SNAW, DECNet and so on. Or they were mired in regulatory and standards bodies procedures such as X25. That was the theoretical reason for choosing TCP/IP. There's a social reason, also. That is, when you looked around, with whom did you want to associate? SNAW people? Bellheads ? I mean, it's clear that the TCP/IP community was where the fizz was, and that's why we stuck with it.

E. Schmidt: So let me ask the OSI question. I remember in 1983 and 1984, when we first started at Sun, we used to draw these diagrams that said we have bundled TCP/IP native, which everyone was using, and we were going to move to OSI at some point in the future. We had a brilliant business strategy at the time, which was that we sold our OSI stack for $10,000, which was very profitable. But of course the OSI stack had no users, and our IP strategy was ubiquitous and free.

H. Braun: And worked. [laughter]

E. Schmidt: And worked, thank you. So how did you see the OSI threat? Did you feel that your research, representing the four of you and your contributions, was literally going to be eclipsed by OSI? Did you figure you were going to take them over? They've ultimately come to your side. You won.

B. Kahn: My general reactions about all that were that we focused on a paradigm that said, ``Build it first, and figure out what's wrong, fix it, and then standardize it.'' And, although, there were attempts at that, in the OSI world for the most part, there was a tremendous amount of attention to process and procedure and definition and everything else. And even in our attempts in the Internet community to help -- for example, when Marshall Rose put a layer of protocol or FC10-06 underneath the higher level OSI protocols to support X400 and X500 -- it still didn't seem to help a great deal.

And the bottom line was that the only threat the OSI community presented was governmental, in the sense that governments were signing up for that as a standard. Even the Defense Department chose this, in spite of the fact that it had expended a fair amount of resources to create the TCP/IP protocols. So it took 10 years to struggle through that. At no time in that entire period do I think there was any serious threat to the Internet community because, as Hans-Werner points out, they had stuff that worked, and so people were being promised all these other things, but they bought the Internet.

E. Schmidt: I think one of the untold stories here is that this took a lot of personal political courage, because you all worked for institutions that had standardized on something else. You had to have the passion and the belief in what you were trying to build.

V. Cerf: I'm inclined to say governments don't always get everything perfectly right. [laughter] But on the other hand, we were at ARPA at the time and a part of the government, so maybe we were the one part that did get something right.

It was the `sticking-by' approach for a long enough period of time, and I think that the decision that NSF made to embrace this whole TCP/IP protocol was absolutely crucial for it sticking in the long term. If they had bailed out at that point, or gone with some other approach, we might have OSI today in its somewhat dysfunctional state.

E. Schmidt: For any of you, if there was something that you could change in history in the past 25 years, in this area, not in general history, what would you change? Do you have any regrets? Any missed opportunities when you think back? It must have been an extraordinary group -- 15-20 people who, working together 25 years ago, built this whole structure.

B. Kahn: Yeah, I would have picked a bigger address space. [laughter]

E. Schmidt: Are you referring to that four-byte problem?

B. Kahn: Well, we argued, actually, over 128 bits at one point, and that seemed excessive. This was 1977 and there were four networks in the world that we cared about. Somehow, you know, 128 seemed like it was more than we would need. Well, we were wrong!

E. Schmidt: Others?

V. Cerf: I think the one regret I have is that it took so long to come into being. It would have been nice if we could have had this 25 years earlier in the form that we now see it.

E. Schmidt: In retrospect, was there a way, or a set of things that could have made it all happen faster? Today it seems to be happening infinitely, but in fact, as is true with most tremendous inventions in society, inventions have a relatively long gestation period, compared with other inventions. And you all will be known in history for this invention. Why did it take so long? Is there some way that you could have made it faster?

B. Kahn: Vint and I are the proud owners of an award from InfoWorld. We got the Product of the Year award for the Internet in 1993 -- 20 years after it had been created. I think it's the only time in the history of that award that it wasn't given the year the product was actually introduced. This was the year that the seeds sprouted above the surface, and as far as that publication was concerned, that's when it was invented [laughter]. I don't know, Vint, what do you think?

V. Cerf: First of all, it took from 1973 to 1983 before the Net was actually rolled out on top of the ARPANET. By policy, everybody had to switch over to TCP/IP. I remember Dan Lynch was a key player in trying to coordinate the cutover in January of 1983. So there's this ten-year period. And one of the reasons it took so long is the first half of that was just figuring out how to make it work. We went through four iterations of design, development, and testing, using these wide-area packet radio, packet satellite, and ARPANET things.

Then, after we got it to work in about 1977 and 1978, we had to implement the protocols on a whole bunch of different operating systems, because back then it wasn't just UNIX-based systems and Mac, or what have you. There were all kinds of different operating systems, and we had them all in the ARPANET. So we had to build that platform, and all the software in order to be credible, telling everybody you had to switch over to use it. Well that took another four or five years to get all that done. The vendors were not willing to go and do this on their own. They didn't see any business in it. So either the government had to pay for it, or we had to cajole and persuade people to do it.

So then 1983 came. In the period between 1983 and 1993, we didn't see any commercial availability of software and hardware, not until about 1986. So look, this is really 10 or 11 years since anything commercially real has been available. And in that time, of course, it's gone pchaaaaaaaa!

E. Schmidt: For example, we have routing. Can you talk a little bit about how routing was invented? I think it was done on you guys' watch, right?

V. Cerf: The first routers were written at BB&N by a woman named Virginia Strausazar, who wrote Internet Experiment Note No.30, describing how to build a router. It would be amusing to read that now and compare it with what we know has to go on in a router today, because it's like night and day.

B. Kahn: The other thing that I would add is that in the early days, we weren't actually working on the Internet as Internet per se. It was always part of some other network project. Ginny Strausazar's work actually was done as part of a packet-radio program that I had started, because we couldn't get enough computing power in the radios that were, I think, national M-16s -- these were the days of the Intel 8008 and 8080. We couldn't get enough memory or computing in the radio, so we put it all in a centralized PDP11s that would broadcast stuff out to them. And that housed within it what became the first gateway between one network and another. We later propagated that to the satellite nets to Europe.

E. Schmidt: Talking about satellites and the future... Hans-Werner, you're now the chief architect of a very, very ambitious program focusing on the next stage of packet switching. Would you talk a little bit about where you think the Net is going?

H. Braun: Well, also in terms of regrets about the past that you talked about, something that I think ARPA and NSF can both pride themselves a lot for, is having driven the performance envelope for networking. One of the major instantiations of that is, of course, Bob Kahn with his gigabit initiative. What I regretted often, however, was two areas that have not developed as fast as perhaps they should have. One was the aspect of ubiquity on a global scale and one was the aspect of sophisticated applications.

People did essentially the same thing that they did 10-15 years ago, turn at SMTP and fire transfers. Now with the Web and with Java and those kinds of things, we finally make the network invisible as it should be.

In terms of ubiquity, something that excited me about Teradesic was the aspect of creating a global satellite-based network that is comparable to terrestrial networks that will bring instant access at any time, at a pretty high performance, to any place on earth.

E. Schmidt: Do you all have, Steve in particular, some predictions for how you think the next 25 years are going to shake out? Care to make any predictions?

V. Cerf: Oh, I'd be happy to, but Steve...

S. Wolff: No, go ahead.

V. Cerf: Yeah, if I could get the guys in the back to toss another slide up. [slide] First of all, I want to make an observation about what is happening here, as Java represents a very important platform. And really what we've been talking about today is the creation of platforms on top of which people can build new products and services. Just as the fax machine would not have functioned as well, or have been as successful as it was, except that it had a ubiquitous telephone network to sit on top of.

Movies, for example, find themselves feeding off of video rentals, because there is three times as much revenue from video rentals as from movie box offices, but they are mutually self-supporting. The video-rental business couldn't have happened except there was an infrastructure of video-cassette recorders out there. Of course, we all understand why there are video cassette recorders out there, so people could watch triple-X movies at home instead of having to go into a theater somewhere and embarrass themselves. [laughter] You have to accept the fact that some infrastructures are created for reasons that you wish they weren't.

The Internet would not have functioned at all if we had not had a very strong telecommunications infrastructure, local area networks, and operating systems that were network-enabled. The World Wide Web could not have happened, except that there was an Internet platform on top of which to put it. And Java, in a sense, sits on top of those other platforms, and creates its own opportunity for products and services.

So my first observation on the future is the huge burgeoning of Internet-enabled and Java-enabled appliances. The television set, VCRs, I can't wait. If my VCR would please get up on the Net and run Java applets so I can just click on the program I want to record, then I'll get rid of the problem of programming the VCR. And oh, by the way, since I'm on the Net, it can get rid of the flashing 12:00, too, by downloading. Once we have that, I'll consider that to be a milestone of achievement!

I have a whole bunch of other examples. Let me pick one and then I'll shut up. Bathroom scales. I think we're going to instrument all the bathroom scales; they'll tell you how much you weigh. They'll be hooked into the Net. They'll record your weight over time. They'll report back to the doctor to keep track of your health, and they'll also report it to the refrigerator which ... Some 15-year old will program an applet that will cause the refrigerator to refuse to open because it knows you're on a diet. [ laughter]

E. Schmidt: That 15-year old will be your teenager.

B. Kahn: I think more than anything else, the last 25 years have really demonstrated that when networking works, there's still lots of opportunity, but we know how to do this, we know it's real, we know that computing and local networking works, and that's real. And what we have seen from the first few years of the Web is the importance of access to information.

And I think what the next 25 years are going to do, more than anything else, is to put content on the map in a serious way. Today, you really can't choose to get most of the things that you would like to get, even though there's a wealth of information out there. And most of the people who value their intellectual property are still reluctant to put it up on the Net when they have a mechanism for selling it, and selling it is the basis of their revenue streams.

I think we're going to see the whole area of content get structured, so that no longer are we going to be thinking about just the pathways that move the bits or the ultimate content that we want to get, but we're going to see the development of the whole intermediate layer of structured information that can move around so it's not like the railroad cars or the slab of beef, but it's actually information packaged in ways that can move back and forth. And I think this digital-object infrastructure is, in fact, in our future, and the Web is simply the first glimmer of that.

E. Schmidt: Steve and Hans-Werner, quickly?

S. Wolff: In 1972, could you have predicted 8,000 Java programmers in one building? Or 4,000 in one room? You ain't seen nothing yet.

H. Braun: I agree with all the comments about applications, but there's one other thing that I would hope to see in the not-too-distant future, given how the Internet evolved over the last few years, and that is better service metrics and service models, so that we have a production-level Internet on a global scale.

E. Schmidt: From my perspective, the four people represented here on the panel are really the heroes of our industry. They did what they did for the sheer joy of it. They established the principles that we all take for granted. It's hard for many of us to remember a time when these principles didn't exist and there were alternative realities. They are truly the pioneers and it's been wonderful for me to be associated with them.

I'd like to finish. Danny Cohen, who is one of the people that worked with this group, wrote a little poem about the ARPANET, at the decommissioning of the ARPANET. And he said that it was a source of inspiration. The poem reads:

``In the beginning, ARPA created the ARPANET. And the ARPANET was without form and void. And darkness was upon the deep. And the spirit of ARPA moved upon the face of the network, and ARPA said, `Let there be a protocol.' And there was a protocol. And ARPA saw that it was good. And ARPA said, `Let there be more protocols.' And it was so. And ARPA saw that it was good. And ARPA said, `Let there be more networks,' and it was so.''

Thank you very much, and thanks to our panelists.

I'd like to ask John to come on up.

John Gage: That was wonderful. There are more slides in that box I think, aren't there Vint? We can illustrate the comment that Bob Kahn just made about content, about the digital object infrastructure. Miko has a way to give you an illustration of the merger of a digital object infrastructure across the network, combining with a new form of visualization, so that you can see content in some new ways. Miko?

[Miko proceeds with demonstration.]

John Gage: Some of you may remember that Don Hopkins built a code browser like that. Brown had projects that let you visualize your way through code in three dimensions.

What we want to talk about now is Java and the Java Conference. We want to talk at a level of technical detail with those that created Java, and then explore with the creators of the Internet how the design decisions are made that yield something that is elegant, that is simple, that we all can use, and that we can have in this explosive, explosive adoption throughout the world.

Now I sometimes think in this history with Arthur, with Bill, and with James who created this, with Eric who watched over them and protected them so they had money and could do things, that we should really entitle this process of developing Java: ``The 125 Votes.'' It's the engineering decision, the application of taste, to decide just what you do.

Let me give you examples. Each of these will bring up memories of a conversation or a battle or an unresolved religious war. Pre-emptive threads. That was easy; that was an easy decision. References. Declared exceptions; that has a battle or two behind it. Booleans, what to do with Booleans. Null key words, which direction do you go? Operator overloading, a topic James has said he doesn't want to get into because if he starts....

J. Gosling: No, that one's way too spooky.

John Gage: We'll come around on that one. Unicode?

J. Gosling: That's when you start looking for spaceships behind comets.

John Gage: Parameterized types; there's a topic. So in these discussions, the votes were drawn from the cultural traditions of C++, ML, the ML2000 community, the Modula and Oberon communities, the Smalltalk communities, the beta community, the ADA community to some degree, and the Lisp lessons.

Now I wanted to ask you: When you began the design conversations that iterated, and iterated, and iterated, did you have overall design rules? Was there something that evolved in what would be kept in the language, and what would not be kept in the language?

J. Gosling: Well, in the very, very early phases, in the first couple of years where the only person doing anything on the language was me, there were a few rules, like; ``Don't do anything if somebody doesn't want it.'' And I have this other rule that sometimes people find really annoying, which I find works pretty well, and that is, if I know five ways to do something, but none of them really stands out as ``this really works,'' then I'd rather not do anything instead of just randomly pick something stupid. And it's not necessarily just outright stupid, but often the trade-offs between them are very difficult. So there are thousands of ways of doing parameterized types. And some of them are essentially macro-preprocessors which aren't really parameterized types at all. And that fits in my view as the aggressively stupid end of the spectrum.

But there are some other ones that are pretty interesting, but the trade-offs are really hard to deal with. Parameterized types is one topic that we've been arguing over for years, and we're still not getting a clear picture there. But the first couple of years of the language were very much focused on producing concrete applications-this was half a dozen guys who were trying to do something that was not a programming language. We were trying to do all this consumer electronics stuff. And in the previous session, Vint goes on about the scale-that you get on the weight scale and it tells the refrigerator not to open. Well, those were the sorts of products we were talking about at the beginning of this project, really ridiculous stuff, which isn't actually all that ridiculous anymore.

So what we were trying to do was build stuff around that. And so one of the really central-unifying concepts was that -- that's what we were trying to build, and we only put in stuff that was needed to do that.

John Gage: And then Arthur joined, other people joined. The group got bigger. Bill became involved. Were there fights?

J. Gosling: I think the word ``fight '' is... some of them got a little violent. I think I ripped some arms out of arm sockets, but not too many.

B. Joy: People didn't walk out too much, but I guess I brought an agenda. Even before Sun, back at Berkeley, we'd wanted a better programming language. We almost put in parts of Mesa together with Seebeck. Then out of disgust, we went looking for something else, and we didn't like C++ very much. So since about 1992 or 1993, I've been looking to put in some things in like parameterized types. I thought we needed something like that to really be competitive, and fortunately we didn't do it yet, because we didn't quite get it right. I'd bring James a proposal every six months, but we've rejected them all so far, and some of them are really good ones.

J. Gosling: Right. But there's always something... I don't know....

B. Joy: I think we're close. I think there are actually three good ones now, so we've gone to this ``embarrassment of riches'' problem. I think we will eventually pick a proposal, but we will have several good ones to choose from, done by smart people, as opposed to ones that we couldn't even understand ourselves. That's always when you know you're in trouble when you can't understand your own proposal.

John Gage: You say there are three and they're out, public domain. Anyone here, who should be involved in this?

B. Joy: Two of them are in the Principles of Programming Language Conference this year. What's interesting is we have internal proposals that looked very much like the ones that James or I had cooked up. Ours, of course, had lots of technical flaws in them. It's a difficult problem. And we have to engage the research community to solve this. It wasn't understood how to do this right four years ago. So if we'd have done it, we'd be stuck with something bad forever.

The 125 things you're talking about were really the tail end of the process. There were thousands of decisions before that, but when it came down to the last year, and when I got very involved in 1995 and 1996, we got to this point where we had a process, and actually to write a more detailed spec. And we said, ``Let's look at every issue we can think of, and make sure we've made some rational choices,'' because we had this small window of opportunity where we can actually change things.

For a while Arthur and I would stay up late, sometimes until 1:00 or 2:00 in the morning, and change something almost every day- little details of the language, you know. I'd say Arthur, ``Let's change this,'' and he'd change the compiler, rebuild the entire world, and the next morning it would be different.

A. van Hoff: One thing that was a great opportunity, was when I started rewriting the compiler in Java, we were forced to make a couple decisions, because I didn't want to have any backward compatibility with stuff we didn't need. So at that point, writing the compiler became a forcing function, and it also flushed out a number of issues, because the compiler that existed at the time was very work-in-process. You could clearly see how it evolved over time, and it supported lots of different features in lots of ways. And throwing that out and doing it all from scratch was really a great opportunity.

At that point we actually sat down with a group of five, and made some tough decisions about how to do things. There were a number of principles, in my opinion-one was that everything had to be decided. There was no single issue to be left open, because this language had to be perfectly designed. Not that it was the best design, but that it had a complete design. You couldn't leave something open like saying, ``Well, how does arithmetic work?'' or ``What is the order of evaluation of arguments?'' or trivial facts that have a great impact on how you write programs.

J. Gosling: One of the funny things about that process was that we went through all this and talked about a whole bunch of these issues -so then the second compiler came out. We thought we had this spec moderately worked out, that it was moderately clear. And then Bill sort of arm-wrestled Guy Steele into writing a real spec, because the initial document I had written was pretty fast and loose. So Bill started editing, and then Guy got crazy on it. And I found it really amazing how much we hadn't even thought about, that Guy plowed through with an incredible attention to detail. It's really a mistake if people ever believe any spec they ever read, because they're always incomplete. [laughter]

B. Joy: There are about 25 pages of corner cases, I think, missing from the spec. There are actually two cases, but it's an error of omission. If you don't distinguish between the implementer that would interface, and the user of an interface, it starts claiming things about binary compatibility that aren't completely true. You can read the book and it all sounds fine, until you realize that there's a case missing. And that's really hard to do, when you start talking about concurrency, binary compatibility, and the corner cases in the language.

One night I remember we tried to figure out all the cases of which casts were errors-which were compile time errors, and run time errors. I was sitting in this office, and I had this 5 x 5 matrix and I'd keep going back to Arthur's office and say, ``Well, Arthur, what about this square?'' So he'd write a test program, and I guess the compiler didn't do the right thing. And we'd eventually taken every square.

But it's exhausting. It's hard to even look at the program to say it's actually testing that square, because the programs look so weird. It's not something you'd ever think of doing in a real program.

John Gage: It sounds like the same thing that Eric, Vint, and Bob Kahn were discussing-different styles of approach to a problem. So if you had to characterize what level -- you were writing compilers. You were doing LALR1 abstracts. You were doing a different form of analysis, and then when you'd print out the entire compiler, I think the story was the compiler had never....

A. van Hoff: One night and Bill and I were having dinner in restaurant in Palo Alto, and suddenly he opened his bag and took out a big wad of paper. And he started going through it, and scribbled something on every page. And it was actually a printout of the compiler source code, and he was actually reading through back-to-front! He came to this one page and said, ``Look, this should be a `not,' not an `and' or something. '' And just by reading through the compiler code, he had found bugs in the compiler, not by trial and error, but just by analyzing the source code! That's one way to approach it. [laughter]

J. Gosling: I think it's the only time anybody's actually printed out the source code.

B. Joy: It was the largest Java program at the time.

A. van Hoff: It was. It was also the slowest.

E. Schmidt: From my perspective, the best story is that they shipped the product, and the team imposed all of this pressure on themselves, because they understood that this was a system that was going to have enormous impact on society. It had to be right the first time.

A. van Hoff: On top of that, when we first shipped Alpha 3, the very first public release of Java, there were still a lot of issues left out, but we were basically forced by Netscape's announcement, and the wide acceptance of Java, to accelerated this whole process.

There was one summer where Bill and I spent the entire summer working late nights, and James too, of course. We were all really involved in this design. To get it done, I remember August 25th or something; it was the day that we had to give the code to Netscape, and that was the drop-dead date. And the weekend before, we were in on Friday night and it was getting later, and later, and later, and we had to get it done, because that Monday, it had to ship.

B. Joy: You changed the clock on your machine to give us an extra two hours!

A. van Hoff: Yes, we actually sent mail to Netscape by moving the clock backwards.

E. Schmidt: This is a hell of a time to be telling them this, Arthur.

B. Joy: We had a list of things we wanted to fix, that we knew we could never fix again, and we were fixing them right up until -- I think I stopped working at 10:00, and Arthur finished at 2:00.

J. Gosling: And one of the biggest things that happened to the language at that moment was that the whole exception model got cleaned up. That, I thought, was a pretty interesting case because, in some sense, it's a total ripoff of the Modula 3 model. And a lot of people from the Modula 3 community had a lot of good experience with it. By and large, when we've done things, we've tried to do things that people have had a really good experience with before. I was feeling like I had used a whole bunch of different exception systems, and I had never liked any of them. And I had read a lot of the Modula papers, and hadn't really talked to many people. And then Bill started pounding the table saying, ``You know, Modula exceptions, these are great!'' And I took a little convincing.

B. Joy: We also borrowed from Lisp, because the Lisp system had the idea of the exceptions in a hierarchy, which was very nice. The hardest part for us was doing it in a way that was backward-compatible, because we had code that used a certain style of throwing the class exception to mean something. It got to the point at midnight when we had to think of a name for the class that was the parent of all exception classes, and it was basically called ``class throw-up'' or ``throw over.'' That was the best we could come up with in about ten minutes, and we had to have it ready for the next day. There was a deadline the next day in five minutes.

John Gage: So, just-in-time deadlines. In looking back on the design process, what's emerged is elegant and simple. What are you disappointed in? To repeat Eric's question about networking. What didn't you accomplish that you thought you could, and what lies ahead?

A. van Hoff: Personally, the one thing that I probably would have done very differently is the way we did native components in the AWT. I think what you see emerging right now are very lightweight component architectures, which were the things we really wanted to do but didn't have time to do then. So part of the reason the AWT is the way it is today, is just because of the sheer time pressure we had at the time. And that's something I would like to do differently.

I must say that Sun has done an excellent job of moving what we did in those few years together forward at an incredible pace, and the transparent component architecture and the JFC and all that stuff is a really an exciting way of taking the stuff that we did in a hurry and making it really work in real enterprise applications.

There are lots of things I would have done differently in that area.

B. Joy: I don't think that in terms of the language spec, we had plenty of time. I felt like we had time to straighten almost everything out. There are a few small things, but someone asked Ken Thompson what he would have done if he could do UNIX over again, he said the system called would be create instead of creat. It's at that level. In other words, the whole thing as a total experience is very satisfying. I guess the answer is that I wish we had the opportunity to change everything we knew how to change.

J. Gosling: One of the things that was really unusual about this was that there was an early phase where there were no time pressures, and there was a small contained user community. And then these folks would come and beat me up; they'd walk into my office with a baseball bat and they'd leave feeling better and I'd be somewhat inspired. [laughter ] And through that whole phase, the language went through a lot of changes. One of the reasons why the first compiler -- if you looked inside it? -- was a complete dog's breakfast was that it was really implemented in about five different languages. And by the time that whole process was done, and we had converged on something stable, and it had had an awful lot of polishing because we had a pretty significant body of code. We certainly had about 300,000 lines of code sort of lying around, and if there was some big language change like getting rid of goto, I could just run an Emacs macro over all the code in the world and do some study about something or other. But these days, that luxury is in the deep past. But at least there was a period where we could actually think about what we were doing, as opposed to just running around being crazy.

B. Joy: I think the summer of 1995 we had the opportunity to really look at the virtual machine as something we were going to be stuck with for a very long time, and look at the language as something we were going to be stuck with for a long time. And really, the careful understanding, and the meaning, and the specifications of those- that gives us the basis for application portability, because those are the rock layers at the bottom. And we had time to do that, largely because the PDA kind of consumer electronics play didn't work. The language then wasn't in as good of shape as it now, or the set-top box really didn't work. We wouldn't have Java as we know it if the first two attempts had failed, or if Sun, and Scott, and Eric, and other people had given up on the project.

E. Schmidt: What's interesting about this project is that a lot of projects are historical accidents-brilliant technology, it just sort of happens. In this case, each of the significant players who were involved had experience in something earlier that shaped their view of how to achieve ubiquity, get momentum, put deals together, and so forth. And so during the crucial time, everyone understood that the stakes were enormous. We would have discussions of the forum and say, `` This may be our last chance in our entire lifetimes to do something like this, this kind of computing model.'' And that's what drove the passion on the team, I think.

A. van Hoff: I remember Bill telling me this one day when we were in Aspen talking about some language issues with Guy Steele. He said, ``Well Arthur, you've got to realize, this is going to happen once in your lifetime. And I've done this once with UNIX.'' This huge opportunity, this is the second time it's happened for Bill, but for us, as mere mortals, it only happens once.

John Gage: I remember, though, there's the Arthur maxim: Do it right or don't do it at all.

J. Gosling: Arthur's law.

John Gage: Arthur's law. This is at 2:00 in the morning, this was a chant.

E. Schmidt: John, we've been focusing a lot on language. It's worth noting that although language is tremendous, it's a language; and a model for computing and a business model, and the whole platform strategy that really drove this, was a combination of things that occurred together. The obvious question from me, I think, primarily to James, but also to Bill and Arthur, is how did the other parts come together in your mind? We talked about exceptions and so forth. But for example, the notion of an applet; was that an obvious thing?

J. Gosling: The notion of an applet, in some sense, was an outgrowth of stuff that we had been trying to do before in getting distributed applications going around. If you look at the original Star7, it had things in it sort of like applets, but they weren't embedded in web pages, because web pages hadn't been invented yet. But when people saw the first web browsers, it was pretty obvious that text and images could be a whole lot cooler if the images were things that you could interact with. A lot of these things are fairly small, but fairly obvious steps that just come one after another.

E. Schmidt: But a lot of people don't get them in the right sequence, and this team did. From my perspective, in terms of the opportunities missed, if you look at Java, the language is an enormous success, and of course it's a brilliant language. James deserves an enormous compliment from the industry and the world for that. If you look at the model of separating the instruction set architecture from the underlying byte codes, that's another key thing. We now have all sorts of crazy languages like ADA being compiled in the Java byte codes, which is amazing to me.

And then you have this core strategy to avoid API lock-ins, in other words, open-system APIs. It is that latter battle, the one which the JFC announcement this morning is so central to fighting, that is so crucial now. If I had one regret, and I'm very, very proud of what the team did, it's that that battle is taking longer, and is a harder battle, primarily because of all the other hosts.

John Gage: In Internet time, compared to the time it took for all the work that Vint and Bob did, this is happening at light speed. The openness, I think....

B. Joy: Not from my perspective, because I wanted a new language in 1980, and this is 1997. It took 17 years from my perspective. I went to the first C++ conference, gave this broad talk about how we wanted ``C++++ minus equals, a little bit more and a whole lot less, '' and what year would that have been? That would have been a long time ago. They never invited me back. [laughter]

J. Gosling: In a lot of ways, it's just like the Internet group. It was in the distant past-the group at UCSD, the Pat Scaloppini machine. The very first company that did a workstation to sell it was a company called the Perq Computer Corporation. I don't know how many people ever knew Perq. They were a bunch of hardware guys who didn't know anything about software, and they wanted to get whatever free software they could. So they decided to build a piece of hardware that could emulate the UCSD Pascal P code, so they could basically rip off the UCSD Pascal P machine.

Some people wrote some interesting software on the Perq machines, and one of the things I wanted to do was get some of that to run on some VAXs and some PDP10s. And so I wrote this rather interesting program that basically took Perq machine code and it turned it into VAX machine code. And that experiment worked incredibly well, 15 years ago. And that idea stuck in my mind. And that's really where the Java Virtual Machine came from.

John Gage: You all write Java code, so I have to ask you. What's the programming environment you use? What do you write?

A. van Hoff: I switched to Windows95 when Emacs started running on Windows95.

John Gage: So Emacs is your world. James?

J. Gosling: Well, I keep hoping that somebody will do something better than Emacs. But as one of the perpetrators of that particular sin, but yes, I still use Emac.

B. Joy: I mostly get to write the eight-line programs that test corner cases in the language. I use them in a shell script that runs them, so it's very, very old technology. Of some of those 8,000 test programs, I got to write about 400 of them. I hope to have more fun some day, writing tests of corner cases of the cast operator.

J. Gosling: It always amazed me that Bill's favorite editor is the UNIX cat command.

John Gage: So in the last moment, what's the next step for Java? What are the basic directions that are being considered, to which everybody can contribute their idea? What's next, Arthur?

A. van Hoff: Well, I've always been in favor of writing everything in Java. That has been my goal since I joined the Java team. That's why I did the Java compiler in Java. That's why we left Sun and did Marimba to do applications in Java, real consumer applications. I think applications -distributed on a very wide scale and on a very wide range of platforms, entirely written in Java, like the Corel Office Suite, that kind of stuff, and obviously distributed with Castanet-is the future.

B. Joy: I guess I've looked at Java serving three communities: the symbolic programming, system programming, and numeric communities. And we've been starting to talk about additional futures for numerical programming, like how do we do complex numbers; how do we do interval like to have them stop programming in FORTRAN and bring nice libraries to the Net for doing simulation, which is part of virtual reality. And the Lisp community, I think what we mostly need is better implementation of garbage collectors that are faster and incremental. And for the system programming community, we probably need to eventually figure out how to do parameterized types so that people can write better container classes once. I hope we will get to those things in the next few years.

J. Gosling: I'd actually like to-other than spending a bunch of my early morning not-sleeping hours-think more about how people do program development. Because there are a lot of folks out there who build these really nice program development tools for doing GUI applications, for doing Beans, for doing interconnecting things -but nobody's really spending any time working on tools for actually building algorithms. How do you build a better sort algorithm? How do you optimize this? And there's a lot of stuff you could do with a tool. One of the goals in Java that I had fairly early on, was to make the program analyzable. One of the interesting bugs in the C design, and this mostly comes from the macro preprocessor, is you cannot actually analyze a program without compiling it. And Java is a very analyzable language, because it's a very declarative thing, and the syntax doesn't have any funny ambiguities that you get from a macro preprocessor. And that's one of these things that I would really like to spend some time on.

John Gage: And so how does everybody here make their way through the class wars? We have Java Foundation Classes. There are a number of classes. How do people develop the taste to distinguish good class architectures, from those that are not so good? What are the phrases you used earlier? Arrogantly stupid? No.

J. Gosling: I don't know; try it on, see if it chafes.

A. van Hoff: I'm for a ubiquitous programming platform. So whatever programming platform is the standard, we should stick with it. And currently, that is the Sun Java application environment. So that's the one that I'm sticking with.

John Gage: Well, we've run out of time. I'd like to thank our panel. I'd like to thank our Chief Technical Officer. He's now a chairman, he's a COTB, a Chairman of the Board, not just a Chief Technical Officer. Congratulations on that. Thank you all for coming. We'll see you tomorrow.