Please note: this text is provided as a courtesy and is not an official transcript.

And now, here to kick things off, once again, your host, John Gage.

John Gage: Well, everybody's awake, more or less. At seven o'clock this morning the foosball machines were going full tilt. Now, explain that. I thought everybody would be running out of energy. We have 34 hours left. You've got to fill these 34 hours. 2,000 minutes left.

This morning we're going to fill your time, we hope, with some interesting discussions. But before we do that, I'll give some announcements about what we're going to do. John Gage proceeds to give updates and information about the day's conference agenda

And now for our panel today. Jim Mitchell. Somebody said in Waldo's session that all of the distributed computing, all of the notions of JavaSpacesTM, weren't those in Mesa? Well, Jim Mitchell, when he was at Park, ran the Mesa operation and as Waldo said. Yes, everything came from Park. Everything had an origin there. So, Jim's going to chair the panel this morning. You can see the names of those that are on the panel: Jim Mitchell, VP of technology in JavaSoft^TM; Eric Schmidt; he now works for some company whose name I forget, but he used to work at Sun Microsystems. He's brought the TCP/IP packet religion all the way straight into Novell. Dr. Eric Schmidt, Chairman of the Board and Chief Executive Officer of Novell. Then, Billy Edwards. Billy is the Vice President, the strategic VP for Motorola Semiconductor. And then, Todd Reese, the Merced IA64. He is in charge of systems architecture and the UNIX World Omni IA64, the Merced chip for Hewlett Packard. And lastly, Bill Joy, another Berkeley guy, who's Sun's Vice President of research and has got a scam going so that he can stay at Aspen and do work and not be bothered by phone calls. And he'll explain just how all that works.

So, with that, let's go to our first panel, which will then be followed by a discussion session that we have been playing with about emergent behavior in complex systems. And so I'll hold up Stewart Kaufman's book. This is Stewart's book, On Home and the Universe, the Search for the Laws of Self Organization and Complexity. We're on that search a bit. And so Stewart will come up after this panel and we'll all talk about whether we are in truth self-organizing. Can we take it easy?

The first panel, Jim Mitchell.

Jim Mitchell: Thanks, John. And good morning everybody, I'm glad you're still awake. The topic of this panel session is going to be 2005, when the JavaTM Platform will be ten. And the idea here is to talk about not just the world of Java technology in 2005, but the world around Java technology. So, we'll be dealing with issues that are not just technical, but social and political as well.

We actually asked on the Web last week for some questions from developers and thank you very much. That was a very useful exercise and some of you will see your questions answered up here.

To set the stage for this, I'm going to try to be the noncontroversial one at the beginning, but I thought it would be interesting just to look at the world of 2005 when we get the first slide up. There we go.

So, what I did here was to look at where various systems are today and ran Moore's law out to 2005 to see what they might look like then. I don't intend this to be controversial as I say, it's just a level set for what the world's going to look like. So, in 1998 here's a standard desktop system of today: 200 to 400 megahertz CPU, people having 16 to 64 megabyte of RAM, unless you're a real power user. Of course, I mean the average one here. And one to four gigabyte hard drives. You extrapolate that out to 2005, we're talking about a three gigahertz machine to a six gigahertz machine, up to a gig of RAM and more hard drive than I know what to do with today, but I bet I'll figure it out by then. My main question to myself is, will it boot faster or slower?

If we took at a completely different end of the spectrum, which is cellular telephones; they're pretty small today, but even today they've got fairly hefty CPUs in them. They come with half to one megabyte of ROM, for some that are more highly functional. They all have some flash to store those 100 numbers that you're supposed to put in there. And they've all got some amount of RAM of course.

Cast your mind out to 2005: they've got a CPU that's faster than most of today's desktops, and memory about like small today's desktops. So you have to think of a cellular phone in 2005 as being pretty much like your desktop today.

In the area of other consumer devices, digital set-top boxes, and I know because we keep talking to the set-top box companies, and they want to squeeze an amazing amount of software into these things. They've got medium-speed CPUs. They tend to have one to four megabytes of ROM, one to two megabytes of flash, and one to two megabytes of RAM. A few years ago that was a big PC. If you look out at 2005, it's pretty mind boggling. The CPU looks like it will be the equivalent of one of today's four-way or eight-way servers. And the amount of memory is actually more than you would have on your desktop today.

I think one of the lessons we take out of that, by the way, is that more and more of what a set-top box will do, will be done in software. I think we see the day coming when all the decompression and everything, the code and everything else are basically being done in software and the only thing you're using hardware for is what physics requires, you know, driving the cable, driving the ether, or whatever.

And, so many of you have your Java rings and we can look ahead at smartcards. Today, those are eight-or sixteen-bit processors. Only about 16K of ROM. A little bit of erasable ROM and that's where the cardlets go and so on, and a very small amount of working memory, just enough to run the stack. Right now about 512 bytes of RAM. But, you go and look at the year 2005 and they're starting to look like the upscale pagers of today on that card. And that's a pretty amazing thing to think about what you could be carrying around as a piece of lightweight jewelry.

Communications are really hard to predict. I tried to hit the average. There are better systems even today than I'm talking about here but, you know, from people's modems, which tend to get 28.8 to 56.6, and if you're using a wide area wireless, then you're back at 9600 bod. But 2005 with the last mile problem of the house solved, we can expect at least a megabit to the home, and wireless of about a megabit. They get to be about the same. And in fact, on a campus network--here I'm thinking wide area, but on a campus wireless network it will be up more like ethernet speeds.

So the bandwidth is really coming, but the lesson I take away from this is in 2005 almost everything gets done in software and of course from my perspective, that's a great opportunity for Java technology. And that leads into the very first question to prime the panelists. But, first we're going to hear from Eric Schmidt, CEO of Novell. And he's going to give us five minutes on his opinions about 2005.

Eric Schmidt: Well, the year 2005 sounds really exciting if we could just get through the year 2000. First it's great to be here, and it's great to see what we've all accomplished in the last few years.

When I go back to what we were trying to accomplish three or four years ago, we had a number of initiatives. One was to have the Java language become ubiquitous, and become the language of computing for the 21st century, the language of electronic commerce, and all of that. We are not only winning, we have won that battle. And this group is testimony to that.

There are all sorts of reasons why the language is right. It's safer, it's the right architecture, it has garbage collection, and it has the benefits from all the work done on the preceding languages.

The second objective that we had was to get an architectural franchise on the scope and scale, and roughly the size of Windows, which was roughly 100-million JVMs. And that's also been achieved. And it's clear that in the next seven or eight years, that number is going to be a lot bigger. My current estimate is about one billion JVMs. And that's important because that creates a vendor-independent architectural language, where applications, new development, and new research can be done against that intermediate form. The problem, of course, with my calculation is that I didn't figure out that there are five billion in the world and they each have ten fingers, and how many rings is that? So, I'm way low.

So, let's assume that we've got a billion JVMs, and fifty billion fingers and there's some number in between. The important thing about is that it's going to be achieved.

The third thing that we set out to do was come up with a set of APIs or interfaces that were vendor-independent. And as you all know that's a great dispute now between the major players in the industry. Certainly on the client, which is a Microsoft monopoly on everyone's mind except Bill. There is an issue around how that evolves. However, on the server side there is no question that Java technology becomes very much a multivendor solution.

If you take a look at the server space, there's a lot of reasons to think that Java technology is the right solution there. Although we originally positioned the Java language as primarily server to client, it looks like the benefits the other way are much more attractive. The language is appropriate for that, it's more secure. People who write server software care about scaleability and performance. You have all sorts of other issues like that. In fact, while the majority of the applications are client focused, the majority of the money, the revenue, the venture capital profits, and all of those things are on the server back end.

Furthermore, there's no dominant player in the server industry. The largest server vendor in the industry is believe it or is Novell with our network product. We have 3.85 million servers installed today and we have twice as many as NT. So that opportunity is there and with our transition to IP, all of a sudden it becomes very interesting.

Last week we ran a benchmark for our version of Java technology running on Netware and the numbers were so good I decided I didn't believe them. So, we asked Key Labs to actually benchmark it and their numbers came in higher. We were pleased to announce on Monday that our Java VM is two and a half times faster than anyone else's--pretty good on the server. And the reason for that is because we skip the intermediate layers in the operating system. We take Java technology and we put it right on the metal. So the thing that you learn from that opportunity is that by taking Java technology and putting it as close to the platform as possible, as tightly intertwined with the system, you have an opportunity for extreme scaleability and extreme performance. By doing this we can grow a much, much larger base.

Where does this take us over the next seven or eight years? Well, if we take the numbers out and we take Jim's projections, we see a couple things. Everything's going to be networked. Bandwidth is going to get faster than even Moore's law, and you still will not have enough of it. Right? Because you never have enough. People will build applications that arecentered on Java technology in a new way.

What typically happens, and you see this today in the press, is that everybody assumes that the opportunity for Java technology is taking existing apps and rewriting them in the Java language, and nothing could be further from the truth. The most interesting opportunity is to build new applications that are enabled by the Java paradigm. And it is that paradigm shift that ultimately creates the new wealth drives this whole industry: the jobs, the customer value, and so on. From my perspective, the size of that opportunity is much larger this year than it was last year. And I think it's getting bigger. I'm obviously very optimistic. Thank you very much, Jim.

Jim Mitchell: Thank you, Eric. Thank you for staying in time. And next, Billy Edwards from Motorola.

Billy Edwards: Thank you, Jim. I'll use up the time he didn't use. Now, for something completely different. I want to show you a short video that we'll start in a second, but let me set it off. It's really coming back to the customers. Where does all this lead, the things that you're creating, we're creating, and we're working towards, what does it mean for the customer? Does it change their life? Do they want it?

This short video will show two young women who are totally nontechnical. We asked them--we explained what embedded worlds are, what the microprocessors are, and how you use them, and then asked them, "What do you see?" What do they want? What would they demand of us in the future? What would they expect of us?

And so what you'll hear is their descriptions of these things, their thoughts about this in their terms, their words. And what I think you'll listen to is--you may have a different reaction to this--that they're spoiled, that they're technically naive, that they're demanding. Well, we the industry have created that. We've given them wonderful things over the last couple of decades. We've created this expectation. Well, what you have here are a couple themes or threads of what's possible.

So, if we can roll the video, we'll listen, and I'll come back and give you some more comments.

video

applause

Think what you may, whether they're technically naive; or spoiled, or there's nothing new there. There are a few things that stunned me.

The reality is we as an industry have created some magnificent expectations and also some awesome opportunities. One of the things we as an industry, all of us here, all of us up on this panel, and the companies have to do is, pull together and make sure we can really enable all that.

Java technology really can enable much of that. They look at the things like the connectivity, the seamless use of information across different systems, devices, networks--all that's crucial. That's what we're talking about. And it's being utilized in interfaces that those women are used to; whether it's the telephone, or a pager, or whether it's your key. It's not necessarily the computer and the interfaces people are used to.

This is all new stuff. But the opportunities are immense. And if we can truly pull together and make it so that things work seamlessly across different devices, networks, and systems, the opportunity is immense. And that's where, if we all work together to take this the opportunity to raise us all up, is there. It's a rising tide that raises everyone.

And some of the ideas they had, some of the thoughts, the things they wanted, are very possible. It's just a matter of getting on with it and building the standards, interfaces, and the capabilities to enable these things.

So, it's a great opportunity. A wonderful opportunity for all of us. We just need to get on with it and make sure we do it correctly together. So, some thoughts.

Jim Mitchell: Thanks. I guess I've got to start thinking of Motorola as the Generation X company.

Billy Edwards: That would be nice.

Jim Mitchell: Todd Reese from Hewlett Packard. Top that, Todd.

Todd Reese: I've got no video, but I think a lot of the same ideas are very common, to build off of what Billy said. I think the vision and the mission that we've been after at HP over the last ten years, and what I think is really going to be the challenge ahead, is moving toward pervasive computing. So, I think a lot of what Billy set the stage for is taking these technologies out from where they are being applied in millions of units, hundreds of millions of units to where we really are talking about the billions. And it really is the naive users that are getting value out of these technologies. It's not just the geeks like us. That's really the promise that Java technology holds.

It is one of those fundamental technologies that is going to change the shape of computing. So, just like the microprocessor, like fiber-based computing, or communications, just like the Web, Java technology is really going to change the shape of moving toward pervasive computing.

As you look ten years down the line, and ask, "Where are we going to be with Java technology?"--and I think unfortunately, again as it was probably pointed out in the video, not far enough--that, we'd like to go a lot faster. I think maybe, to look at the potential for Java technology, you need to step back and say: "What's the opportunity on a broader scale on even a longer time scale?" then maybe step back and say, "Well how far along will we be on that path ten years from now?"

Trying to think of analogies and where we might be with Java technology, I was thinking of something this morning, that was maybe a standard that might have been really valuable is, I don't know who all remembers it--but there was this idea of one language: Esperanto. It never made it--came in a little bit too late. Well, what if that had been established before there were billions of units, billions of humans, before there were hundreds of warring factions all with their cultures and their languages? What if in the adoption cycle we'd been able to catch a single language throughout the world? I think the Java language offers that single language for the world of computing.

That single language will help our productivity. It's going to help us drive toward pervasive computing. It's really going to help the pace of change across the industry. So, it's that foundation of a pervasive technology that is most important to the pace for Java technology in the future.

Certainly, as we look forward maybe ten years, and ask, "Where will it be? Where is Java technology going to be successful?" Certainly there is no question that in small devices, little personal devices, it's absolutely an ideal technology. That's certainly an area where at HP we're going to be driving forward to have it be pervasive in any of the portable personal devices. I think it's an ideal fit there.

A second critical area that I think is very realistic for the broad adoption and the pervasiveness of Java is in the management of these billions of devices. That's the biggest single problem we have in heterogeneous network and systems management--the interconnection and management of all these devices. The Java programming language is absolutely the ideal technology to address this problem.

The tougher problem, which I think Eric touched on and where I think there is the big payoff, is the whole server infrastructure. Can we really have the Java programming language be the foundation of the data center of the enterprise server infrastructure? That's where the big, nasty problems are. That's where it would be outstanding if Java technology is pervasive and becomes the foundation for this new wave of applications.

Where are we going to be ten years from now? I'm not really as sure. If we look back ten years, we were just starting to get UNIX adopted in the data center and being viewed as a commercial alternative to the mainframe. Let's hope we can get a larger pace of change and have Java technology be more pervasive in that area over the next ten years.

I think those are generally where we'll see the key areas of adoption--what we'll see as the pace of change for Java technology. But, there are a couple of very critical elements in terms of Java technology being successful.

To be pervasive, first it's got to be cheap, and second it's got to be everywhere. So what we need to do is make sure that across the board we're driving the volume--driving the numbers up on Java technology. And when we drive it everywhere, we even have to drive it to places more distant than the third world, like Redmond maybe, and make sure it's pervasive there.

So, I think is absolutely critical to make sure it's adopted everywhere, and that it really becomes volume-pervasive and cheap.

I think the third key area is that we must have fast a level of innovation. We've got to have everybody innovating and moving Java technology forward. We're not going to be able to move on one controlled standard. That's a very delicate balance. But, we need to be able to try to tap the innovation and all the opportunities that the set of folks who are participating here--all of the brains in this room--need to be moving Java technology forward. We can't just have one controlled standard. But, we do need to keep that compatibility, so it will be a delicate balance for us to strike.

Maybe as we step back and ask "Where will Java technology be?" We should ask, "What's a realistic objective for ten years from now?" Maybe stealing something from another caffeine drink, like Coke's objective was to have a Coke within a 100 feet of every person. I guess ten years from now I'd like to make sure that Java technology is a little closer. It's maybe within one foot of every person. Let's make sure that's the objective and I think that's perfectly achievable for us with Java technology in the next ten years.

Jim Mitchell: Thanks, Todd. And our last panelist this morning, the ever- controversial, Bill Joy.

Bill Joy: Thanks, Jim. I'd like to talk about Java Platform, breaking it down into the libraries, the paradigms for computing, the language, and the virtual machine. So a little more technical perhaps than the previous speakers.

What's happened, I think, with Java technology is that for the first time we are seeing the emergence of broad libraries of software components--reusable software components--because the language has safety, and is object-oriented enough so that these libraries can be built. And I liken this a little bit to the emergence of the integrated circuits, and the dual inline packages, and the PC boards that are the applications where you can plug those in. So, it's a kind of a holy grail that we've had for a long time.

A lot of the ideas for the Java programming language started in languages like Simula 67, in roughly the same time frame as BCPO, which was a predecessor to C, about 30 to 40 years ago; and people who worked on these and languages like SmallTalk and C++. But these levels of these class libraries and the languages never became popular enough so that we could build these software ICs. In this book, The Almanac, you can see the classes that we've done and Sun with the partners largely today are sort of the analog of small-scale integrated circuits. The 74LS. The kind of books you saw from National, and Fairchild, and AMD, twenty years ago. Perhaps JavaBeans^TM components are more of a medium scale of integrated circuits, but slightly more functional.

I think we're going to see emerging over the next few years, say between now and 2005, several flavors of even higher-level integrated components. Higher-level than JavaBeans components. I can't say what those are, but if you take this analogy of integrated circuits, it seems quite likely that some higher-level components will emerge.

I just looked at the numbers of libraries and classes that we have. It appears that the number of packages and classes are roughly doubling every year. I think Alan said well....We feel like we've done a base seven. We're going to work on performance and compatibility. But what we expect for the next phase is lots and lots of other companies building packages and classes of Java software to meet specific needs. And just extrapolating to 2005, at the current rate that would mean there would be about 8,000 Java packages commercially available with 200,000 classes. Obviously this is because there is an enormous range of possible applications. And there are going to be many, many software companies started, major software companies--like there were IC companies when integrated circuits came along--manufacturing large numbers of these classes. It's a wide open market. Almost all of those classes don't exist. Most, I think, won't be written by Sun or even today's leaders.

But, what's going to be really important, then, in the process of those packages all emerging, is that we'll have really good ways of testing and integrating those components together. A whole industry was built up around integrated circuits and CAD, and hardware and software test equipment. And so I would predict there will be a whole industry, and major multibillion dollar companies doing software integration, testing and building reliable software.

I'm going to talk briefly about the platforms. Obviously, there's going to be a range of different kinds of devices with the Java programming language in them. But, I think one thing I predict is that the average user interface a person will use in a desktop machine, or any of these devices, will be a lot more like the Intertainer demo we saw, or the kinds of user interfaces we see in Kai Power Tools than we see in the desktop of today. Much more interactive, varied user interfaces, not just the mouse and menus, and scroll bar types of user interfaces.

In the area of distributed computing, I think perhaps, even as early as next year, people will begin to realize what this remote method invocation is, and how incredibly important it is. That it's really a very practical form of agents and how JavaSpaces is like a directory of active objects, or a directory of agents that you can use. And young children will understand how to use this. They'll see objects on the screen and realize that they move around and they can have a list of objects, or a menu of objects and they can just execute them. They'll expect them to move across machines completely fluidly. And there'll probably be an additional paradigm or two for distributed computing.

Finally, to talk a little bit about the Java language and the Java Virtual Machine. The Java Virtual Machine is the bedrock on which all of this is built. There are always a lot of proposals for additional functionality and compressed class tile formats and other things. I think there might be one new version of the class file in the bedrock format between now and 2005, but I'm not absolutely sure even one will happen because it's such an important, solid base that we'll look for any technical alternative to that.

In terms of the Java programming language, I think over the next period the language will be very stable. There's obviously a set of technical areas that we've been working on. The typical areas are involved with stronger checking, so that you can have a stronger level of confidence that your program works before you run it. Those things can be done with testing tools. We've been working with a lot of people in research on things like parameterized types. But that's very difficult. That would catch more bugs at compile time. I've wanted to do things like have primitive data types with units, so instead of declaring a float F you can have a float variable that is in meters, and then one that's in seconds, and when they are divided one by the other, the result is meters per second and that would catch more bugs at compile time.

In the area of numerics, the numeric people want things like integral arithmetic and better exception handling. Some of these things might in fact happen with preprocessors or other mechanisms so that we don't have to change the base language. And James has been looking at things like that.

But, I think these are areas where we'll see better tools for writing applications, which catch more bugs, and be able to write even more reliable software.

Finally, we don't think the Java language is the last programming language. What we think is that there's a strong chance between now and 2005 another programming paradigm might emerge that would run in concert with the Java language. And I personally think such a thing would be essentially a non-imperative programming language where you don't have to write your program as a sequence of steps. It would be more data-driven, or constraint-driven, or logic programming, or something like that. And you can easily imagine a way of expressing computations in very short and interesting ways and then use the underlying universe of Java objects and Java classes as a base on which to build that higher level programming paradigm.

Jim Mitchell: Thanks, Bill. So now we're going to ...

applause

Jim Mitchell: Thanks to the whole panel. We're going to go through a series of questions that, as I say, came in from the Web, and I've received lots of suggestions over the last couple of days. Given what we've just heard there's a natural lead in to the first question. Mundane as it is, I'd like to hear from the panelists what they think about how big the Java software market is going to be in 2005, and I think I'm going to pick on Eric first.

Eric Schmidt: Well, the current software market is somewhere between 40 and 50 billion dollars a year depending upon what assumptions you use. It's reasonable to assume that in the year 2005, every single piece of software will have Java technology in it in some form. So, in that sense if you allow for mixed models, it's going to be fifty billion times whatever the multiplier is. The software industry is growing 20-30% a year. So all of a sudden we get to 100 to 150 billion dollars.

If you look at the Java-only market, I don't think we know yet. It's compound growth rate is enormous, and it really depends on the creation of this new set of apps.

If you take a look at an example ten years ago, would you have understood how important the enterprise resource planning, the ERP market, Oracle, SAP, Sybase, would have ended up being? It's not obvious. But, today it's a huge factor.

Jim Mitchell: Anyone else have an opinion?

It seems to me we've progressed from having a small number of shrink-wrapped applications in high volume to downloading applications from the Web, interactively, or as applets, or whatever. And in fact this trend towards customized applications is going to continue so that the number of applications, and the size of the software industry will probably extend beyond what we traditionally think of as boundaries, as things that were done more as data for existing programs to what, in fact, are cast as applications.

Todd Reese: I think also outside the traditional software business you've got the embedded systems, the small devices and we certainly find as much software on some of these appliances as you have on your enterprise system. So, again, a huge potential to radically increase even the numbers Eric talked about. But, it's big and there's plenty of opportunity for all of us.

Jim Mitchell: Okay. I think we'll move on but, if I did my arithmetic correctly, if you've got $100 billion and that's 10 to the 11th, there's about 10 to the 4th people here that are programmers. Hey, that's ten million each.

laughter and applause

So, let me move along to our next question. How do you see Java technology supporting mobile devices, especially mobile devices that exploit network computing? Let's give Billy a shot at that first. I'm sure everyone will have an opinion.

Billy Edwards: Oh, I'm sure. It's natural. I mean, that's the simplest thing I can say. The devices that are out there now, you know, mobile computing are--we're just seeing the beginnings of a lot of different things happening. Some of our devices, Nokia's and other big players in the market, HP's, that are.... It is a natural when you start thinking about the ability of the client-based apps, applets and so forth, versus the servers and whatever's out there. Once you start getting those talking to each other in a common way--that is Java technology--it's open ended. It's back to the question of how big this is? If we truly make that happen, it could be huge. If we fragment it, it's going to be a lot smaller--two very different scenarios.

So, whether it's the things you take with you like the phones or the page writers or whatever it is, you put things in them so that they will talk to the network; and they've got to talk a common language no matter what the network, no matter what the system. So there are immense opportunities. And it's a natural outcome, once you get that ubiquity across the systems and devices.

Jim Mitchell: So, who will the servers come from to support this?

Billy Edwards: Someone will offer them up.

Eric Schmidt: If you take a look at the size of the market of these phones alone, you get a sense of how big this opportunity is. What we've seen over and over again is specialized markets that have been isolated, that have become networked and you get a network effect. You get positive returns. So, imagine when every one of these phones has an IP address. For one thing, it helps us run out of IP addresses, but more importantly, connections increase.

If you look at the history of networking--networking among trains, networking among airline industries, networking among the computer industry-- what happens is the moment everything gets interconnected, there is a big shift. I'm going to talk about that later in the second panel. The important thing is that they really are discontinuities. And when all of these specialized devices get interconnected through a relatively continuous and accessible framework for IP addressing and so forth, you need a coherent platform for execution; what choice do you have but Java technology?

I think that's another key element. We're at a time where there aren't pervasive installed islands of other technologies out there. I think we've caught this right at the right point of the adoption curve. I think everybody does see Java technology as the natural choice. There aren't other entrenched technologies out there, and, I think, that's a key element that's really going to help the acceleration rate. And it's so natural to pick the Java programming language, natural for Java technology to become that one interconnection scheme.

Bill Joy: I guess my feeling is that these small devices have a problem with software quality. We expect them to behave like appliances and be extremely reliable. And the amount of software that's in them is going up so much that we need a well-designed language like the Java language with good testing tools and a high-level collection of objects, because it's just hard for people to write software that's that complicated. Especially, as a lot of us are carrying too many of these devices, so we're going to expect one device to behave like several different devices, and even behave like things that the designers didn't have software for when they shipped it. And that's going to require very well-tested software, and a very, very good model of how the device works so we can ship new embedded software to old devices and expect it to still work.

If I can add to a comment from Bill. There are two aspects to that, and one is a comment you made earlier, is how fast can booting up change?

With embedded devices, people expect a diferent performance. It's not the computer, it takes seconds to boot this portable phone as you power it up.

The second is, how many of you had your phone freeze on you? Not many probably, but the reality is embedded devices, whether it's pagers, phones, small devices, something in your home that's running the air conditioning and heating system. Booting is a different issue. Freezes are a different issue. It's a slightly different mindset from a computer, which you use in terms of desktop standards. And that's a mindset. It's not impossible, it's just simply a mindset shift that has to be made as we go more and more into the embedded world.

Jim Mitchell: An entirely different area. More political I would say. So unless 100% Pure Java^TM penetrates Microsoft tools and applications markets, it won't be possible to establish Sun's Java technology as a standard. Do the panelists think this is possible given that so far Microsoft has been 100% successful in disintegrating every effort to dethrone its empire.

This is not my opinion. This came straight from the Web.

Which doesn't make it true, just because it's on the Web, Jim.

Jim Mitchell: Right. I understand.

I disagree with the premise in the following sense. Microsoft has done an excellent job in a couple of areas. There are some other areas, Intuit being one example, AOL online services being another where its success has not been so good. But it's sloppy reasoning to assume that just because you've done well in one market you'll do well in another.

I don't think there's any question that it's important to have lots of different players implementing Java technology, and that everyone wins by having an interoperable solution. We're going to see the same issue, by the way, in the Internet in the sense that as vendors get more and more contral around TCP/IP, there will be tensions that are proprietary. And the check and balance on that is having a vibrant market, because ultimately if the consumer insists on interoperability then this issue does get handled through the market.

Jim Mitchell: Anyone else want to touch this one?

I think it's going to again be an area--not only is it practical to imagine that there are going to be other players that are going to be successful other than Microsoft, but again, Microsoft is now dominant in a market of tens of millions, hundreds of millions of units. As we talk about billions--we talk about the devices that are going to lead the technology here, they are smart enough to know they're going to need to follow where there are pervasive standards, where there are other places that they need to interconnect into. So, I think the landscape will change somewhat, but you can't just presume that Microsoft will continue to be the center of the universe.

Similarly, though, we can't leave them out. We've got to go ahead and include them. We can't imagine they're going to go away either. So, I think that's another naive assumption that we can't make.

Bill Joy: It seems like the Microsoft engineering people that I've talked to, understand the benefits of Java technology. And I think most of them know that Java technology is a platform, even if they won't go on it. The executives don't want to say those words. And, you know, I don't think anybody is really fooled by the J++ kind of maneuvers. Once you've written most of your applications....

applause

Once you've written your application in the Java language, even if you wrote it with their new platform-dependent classes, porting it to another platform set of platform- independent classes is that much of a smaller step. So, you know, even to the extent that people who wouldn't do Java programming do it because of this platform-dependent Java technology, because they're that much closer to being platform-independent.

So, I think Microsoft is damned if they do and damned if they don't. It's a slippery slope towards platform-independence, which I think the customers clearly want. There's clearly an enormous benefit for our industry.

Jim Mitchell: See that was a little less controversial than I thought. Let's go to the next question. Another one from the Web. I rather like this one. So one measure of success should be how many people will be using Java technology- enabled equipment, and don't even know anything about Java-enabled technology and how important is this as a measure of success?

If I ask Bill Edwards, I already know his answer. So, he's going to have to come in second. I'm going to ask Todd instead.

Todd Reese: I think it's about the same as Billy's answer. I think that's the key measure of success. And I think that will be the true measure of: "Can we get there in ten years? Can we have this be pervasive, and have this broadly applied outside the traditional technology markets and the technology folks?" That's what we ought to be aiming for.

I think Java technology will absolutely sweep across the current technology infrastructure. But it's: Can we use these devices and technologies to get computing more pervasive--to get out there to the billions of users, and billions of devices? That's the big opportunity that I think we ought to be chasing after.

Billy Edwards: Of course I'll jump in. The term I use is what I call everyday miracles, where it just happens. And if you think about it in one sense, it's a miracle when it happens, but it's an everyday event. When do we get to the stage, when you go to your hardware store and you buy a light switch that is Java-enabled? It's that pervasive that it can have a reasonable amount of connectivity and intelligence to talk to other things. It is when you get the pervasiveness to that degree. I don't know how fast it happens, but when you've got it to that degree, you can start thinking about it as Eric said, the connectivity, the effective network at that point is so huge that we can't even begin to think about the possibilities. But, it's huge and it's basically a market that grows and lifts all of us in terms of opportunities for the business, for the growth and what might be created.

So, I see it as, once you start building this, it just kind of feeds on itself to a great and grand degree and just keeps rolling. It's huge.

Jim Mitchell: Good. Thanks. Another question from the Web. I love this one. Why do you assume that we'll even be talking about Java technology in 2005? Won't something else have replaced it? And Bill alluded to that so I'm going to pass this one to Bill Joy first.

Bill Joy: I don't think so, because we've worked on the technology that became Java technology from the midsixties until now. And I think that anything that would have replaced it as a programming paradigm for general purpose programming, not for the kind of specialized programming I talked about, we'd probably know about it already. There have already been two failed attempts.

The state of Java technology is sufficiently close to the state of the art that there could be something--somebody could try to introduce something that was, you know, like the Java language but a different spelling, but I'm not sure that that would be very successful at this point in the marketplace. So....

applause

I think there are two different answers: One is we're going to be talking about Java technology in the year 2005, because they're still talking about FORTRAN and COBOL in the year 1998.

laughter

I mean, how many of you were born after COBOL was invented in 1956, or FORTRAN in 1958? I think it's pretty clear that these things are around for generations.

The other reason to think that Java technology in its current form will not be replaced--obviously there'll be additional initiatives such as Bill said--is that Java technology occurred because of a unique alignment of a set of things: the development of browsers; the network getting the globe connected; the hype that was associated by people discovering that everybody was interconnected, but they weren't all the same. Plus the need to have choices in the industry. All of that occurred at a specific point in time, somewhere between 1995 and 1996. It's not clear to me that the same set of issues will occur in the next five or ten years.

Bill Joy: The Java platform doesn't have to be the only platform to be successful.

Jim Mitchell: To address a different area all together, there's the area of education. Thanks to John Gage and others, we've brought wires up to a lot of the schools in the country, but that's about as far as it's gone. There are still only a few computers in each classroom and the teachers are scared of having more because they can't do the system administration. So, it would be interesting to consider whether or not Java technology in the form of electronic textbooks will actually arrive by the year 2005. I'd be interested to hear what folks think it would take to make that happen.

Bill Joy: I think we know back in the Green days we were really excited about the idea of the manual or the tutorial material so that Java technology could be used on a web page with Java programs in it that you could play with. That whole idea is technically possible right now, it's just a matter of somebody writing a physics textbook with simulations in the pages. It's a lot of work and it doesn't get printed and go through the traditional publishing process, so maybe that's why. It's not the well-worn path for authors.

Jim Mitchell: But the students have to have something to run it on too. In New Zealand one school district mandated that the students have laptops. They all carry it to school and home and bring computers to the classroom. If you put a kid on a bus with a $3,000 laptop, he's going to get mugged. And that's what happened. So, I think we also need devices here. So, I'd be interested in hearing about that.

Todd Reese: Let's take a little different shot at it, let me take the word textbook and think about it differently. The reason we all had textbooks and studied was to learn about something we could apply. That's what they kept telling me in school, that I could apply it in real life. But, the reality is that you really learn it when you finally get in the middle of a problem where you have to use it.

Instead of a computer that looks like an electronic textbook, what if there's a device that actually is with you all the time and contextually it can tell you if you're making change at the store. By the way, I have my young kids pay at the register to make sure they can practice their math. Did they get the right change and so forth? Maybe we take the next step and practice that. The device also tells them, "Here's a situation where some physics law applies, or here's something where this is chemistry operating." We should start taking it to where it's contextual learning in the every day world, so you make it very real to students. Is that a textbook? I don't know. But then you start making the learning paradigm very different and hopefully more powerful.

I don't know what the interface looks like. I don't know how you do it. But then you start to change the concept of learning and where you use "the text," the stuff in the textbook in the place you're using it. It's very different. If that happens, I think it's powerful and it's all over the place.

Billy Edwards: Again, if we take the curves out in terms of where are those devices going to be in the year 2005, I don't think it's going to be a $3,000 laptop. It's going to be this 100 dollar, 200 dollar device that is my library, and I can load whatever I want overnight, take it along with me and it's going to be instantly available, very cheap, and very pervasive. I think the natural technology curves are going to enable a class of new devices. I don't think it is at all unreasonable to expect that it is going to be as natural as when we were in school, using a calculator on a physics final. Who even asks that question anymore? It's just going to be cheap devices that will enable that to happen.

I think that there'll be textbooks starting in areas like the science laboratory, where the textbook is a software physics experiment, or software chemistry text to do things that you can't do. Probably by the year 2005, there'll be 1,000 such titles because that is an area where you would need lab equipment which is as expensive as the computer.

Jim Mitchell: So, I got it. I can do a simulation so I don't have to use dangerous chemicals and things. I can sort of build my own nuclear device and see how it works. So on to a related subject: What's going to be the most common piece of Java technology enabled jewelry? And I guess I also wonder if it will it be a piercing type or not?

laughter

(who?) Well, rings are one possibility. There must be others.

Todd Reese: I'll put in my request for Billy, a smart pager that only gets me when I want it.

Billy Edwards: The obvious answer is the watch. By the way, we always make pagers with on/off switches.

That's a little smarter.

Billy Edwards: You can do that. It's hard to say. I mean, we were joking earlier about the Java piercing, whether it's earring or navel ring or whatever, that can monitor your health and your blood gases and who knows what else, maybe your hormone levels so you can communicate with the person across the table there. Yeah, she's got the same thing. It's a go, guys. Let's go.

laughter

It's hard to say. I mean, this is where creativity is going to be really interesting to watch.

Jim Mitchell: What is our world coming to?

Billy Edwards: I don't know. But, it's fun as hell.

Maybe for you.

Things need to get small, it's obvious, or this is not going to work so well.

I think the more serious question is not what is the most common one, but how many will you have? Right? It seems to me, you know, you've got rings, watches, wallets, cell phones, pagers, eyeglasses, thank you.

Jim Mitchell: You can't see it, but when everyone got up here, they had to offload their digital equipment, and this table is littered with pagers and telephones and things. This was the general comment from everyone, we said, "Okay, turn them off so they don't buzz, or ring, or whatever."

How many of you have been in theaters where the first thing do before the movie is say, "Please turn off your cell phones?"

(multiple voices)

Jim Mitchell: That leads very naturally to the next question: "When in the period between now and 2005 does Java technology become a check list item for any device that's capable of doing communication? Maybe it's this year. Maybe it's 2000. Maybe it's 2005. Maybe it's later. Are there any opinions? You've got to have it if you're doing digital communication.

Eric Schmidt: Clearly it's already occurred from a standpoint of the company. Every company that's in these spaces now has a Java technology strategy and has announced one. However, it's an early-adopting market, so they tend to be in specialized devices. How quickly they get down to the $10 or $20 kind of price point is a matter of debate. I think it's pretty soon. If you compound it, it's a couple years or less.

Billy Edwards: To add to Eric's point, it has already occurred at one level, a very macro level. Within specific market segments it will happen in different phases. Again I think it's driven by the value and need for connectivity. If you're not connected to the network, the impetus is a little slower. But as soon as you say that the real information, and I've got to talk to other devices or systems or the network, however, like I said, you want to describe that. I think then it becomes a checklist item, that it's got to be there. Because otherwise you've got a dislocation that you can't get past. I think when that happens in a given market segment, that is an impetus to say it's there. It's got to be there.

Bill Joy: I think we're one development cycle away--maybe two to three years-- from getting a large double digit or 50% of the communications devices. It's like the analog to digital cell phone thing. For whatever reason the first few may not be hits with the customers. You need some hit products to drive the volume. I think it's time for people to figure out what consumers really want and how to use the programmability and downloadability.

Another important driver, beyond what Billy said about the connectivity of these devices, is that any device out there that you want to manage, that you want to update software, there's a whole class of things where it's natural to choose Java technology. That may be one of the things that drives the wave of adoption, into a whole new class of devices that might not naturally need to be externally connected but need to be internally connected, for service management applications like MAP.

Jim Mitchell: We've got time for just one last question,which was asked from the Web. If in 2005 WindowsNT is the dominant enterprise OS, how will this change the Java Platform? Eric probably doesn't agree with the premise.

Eric Schmidt: So which service pack was that? The more likely scenario is that over the next five or ten years, a new set of platforms that are not UNIX or NT will eventually emerge. If you take a look at what's going on and there are people here in the audience who are part of this--every significant research center, university, computer corporated research group that I'm aware of has work on fundamentally interesting, different architectures for platforms based on Java technology.

So it seems to me that the more interesting question is what happens to UNIX, NT, and so forth in a world where this new category of Java platforms that are scaleable, powerful, run the right apps, mission critical and all of the things that corporate customers care about. I'd be itching to see how that plays out.

The reason we don't see that today, as we discussed earlier, is that there is an infinite amount of stuff that's required, which is being built on Enterprise JavaBeans to connect to Legacy networks. You simply can't invent a brand new platform and ship it into the corporation. You have to have a brand new platform and you have to interconnect with everything that they've bought for the last forty years. Witness the year 2000 problem as a good metaphor for how complex that problem is.

I disagree with the question. I think the key message is that we as a group have an opportunity to make real progress because of the paradigm shift that Java technology represents.

Bill Joy: It seems like if you're using WindowsNT in 2005, you'd probably be spending 80% of your time running curved Java Enterprise applications. Because it seems quite clear that that's where all the creative energy except perhaps in Redmond, is focused right now. There's a lot more creative people that don't live in the state of Washington, on the rest of the planet, then there are there. I believe there'll be a lot of great stuff created from companies that we don't even know the names of yet, which will be the dominant applications on those enterprise machines in 2005.

The corporate customers are spending all of their time complaining about manageability, integration, consistency, and coherency. These are all issues that people in this room are busy solving. There's every reason to believe that becomes an interesting story for the Enterprise.

Jim Mitchell: I found something I can agree with Eric on. And with that, I'll stop because that's a great place to break. I would like to thank the panel very much for their time and for their opinions. On to John Gage.

applause

John Gage: Thanks very much. We could keep going on this line, and we're going to keep going for a bit in a slightly more abstract sense. Miko Matsumura, if you would come up. Miko will demonstrate a little bit of what Eric was talking about. It's not coherence that's planned, it's emergent coherence. It's emergent order. Can things that are complicated combine into even more complicated things in some sense on their own? Are there underlying movements, or is there an underlying mechanism that leads toward coherence?

Miko: What I'd like to show you is a very simple principle--how certain simple properties can illustrate complex behaviors.

Miko continues with a demo, where on a laptop, he first interconnects very large numbers of buttons with threads, and then clusters of buttons, then he interconnects the clusters, and so on, until there are huge numbers of buttons. Miko shows how he is able to plot and graph these buttons. He goes on to relate this interconnectivity to the Internet, and illustrates with a map just how many, many people are interconnected, and how these numbers are constantly expanding over time as more and more people find value in the Internet, and connect to even more people. Miko explains how the study of this massive interconnectivity is known as "complexity mathematics."

We have for you today one of the premier researchers in complex mathematics. Someone who is studying how these things impact social and economic webs. We're all here at this conference. Each one of us is like one of these buttons and we're connecting with each other in ways that I think are not visible to us today. So, I think that this is going to be an interesting conversational topic to try to understand how all of these systems come together and how they behave using the tool of complexity.

Let's go over and have the conversation with Stewart Kaufman.

John Gage: Let me start with this demo. We expanded the number of connections. Bill just said that if objects are buttons, that we'll have 200,000 new classes by 2005, so what happens when you expand the buttons, when you expand the objects that are becoming interconnected? What happens from that, Stewart?

Stewart Kaufman: We're entering an era right now where we're needing to look at how economic growth occurs in a different way, John. Let me try to define an economic web for all of us. I think you all know the notions of technological complements and substitutes. A screw and a screwdriver are complements and a screw and a nail are substitutes--everybody knows that.

The interesting thing here is that the economists study an economic system as if the United States were a global economy made of single stuffs called gross national products. Now, if you actually think of economic growth, any single sector saturates after a while. So if we were producing a single stuff in the economy, growth would have stopped a long time ago. Instead, think for a moment about what an economic web is. Think of a graph like the buttons and threads referring to demo in which each dot represents a good and it's connected to those goods or services that are its complements or substitutes. So for right now put undirected arcs of two different colors, complements and substitutes among the dots.

We are living in an economic web of vast complexity. In fact nobody's ever looked at the actual structure of an economic web, and part of the reason I think that Java technology is so fascinating is it affords us an opportunity to look at what is in the making rather self consciously.

But a word about growth itself. 40,000 years ago when we were all kids, if you wanted a rabbit for dinner you bloody well went out and caught a rabbit. Nobody had to catch a rabbit last night if anybody wanted a rabbit for dinner. There's probably 30 restaurants within a couple miles from here where you could order a rabbit for dinner or part of a rabbit. Something's happened and it's the diversity of the economic web, which had ten goods or services maybe 40,000 years ago, mostly made of rocks. Now, it's still made of rocks--they're cut out of silicon. So the economic web has exploded in diversity. The biosphere has exploded in diversity in terms of the number of species that are around. The chemical diversity of the biosphere has exploded from the pure organic molecules to billions of organic molecules. We have no theories to understand this explosion. And it relates to this notion of all the objects you've got in Java technology and the adjacent possible, if I can call it that. The technologically, chemically, sociologically adjacent possible that we're flowing into, that the two young women in the video were telling us about.

So, we're in this explosive course of creating vast numbers of new goods. The very structure of the Java-empowered web affords the possibility of making more goods and services, where we can all create precisely the value you are talking about.

An interesting thing with Java technology is that we've had this software industry that has been incapable of having these interactions because the software components we were creating were sufficiently low level and we couldn't begin to plug them together. The analogy I was trying to make is once we have the idea of the printed circuit board and the dual in-line package, we can plug the things together and another level of the hierarchy opens up. So, a level of the hierarchy has opened up for the software industry now and we can start to see all these complex interactions that are reflected by the emergence of the larger clumps in your little demonstration, which represent economic value as the solutions to problems.

And it's fascinating because we can actually watch it with Java technology. Think of all the organic molecules, the kinds of organic molecules that exist in the biosphere. Now, think of every kind of chemical that is one reaction step away from the molecules that exist now in the biosphere. Let me call that the adjacent possible, a phrase I used before. The biosphere is obviously expanding into the chemically adjacent possible, into the organismic adjacent possible in terms of species.

This diversity explodes and now we've got objects that can interact with one another to allow the generation of objects that are going to create value all over the place. It's extraordinary.

With RMI, Java technology allows groups of objects that are like cells, applications to contain these objects in order to exchange genetic material because I can send a piece of code from my application to your application the same way that bacteria might evolve drug resistance by exchanging information. Actually exchanging hardware is what they're doing.

This leads us to a fascinating problem. When Darwin told us about evolution, he assumed gradualism. If you don't have gradualism, you don't get evolution, roughly speaking. Whence cometh the gradualism? Well, it's an achievement of evolution itself. I mean, if you made a maximally compressed computer program, you could not evolve it very well by playing random mutations in the code because it would be so compressed that it would have no redundancy, so you'd screw up when you tried to make it better.

So, there are complex things that can't evolve, which means there's a condition of coevolutionary assembly for objects as they coevolve with one another like bacteria. This will be how the Java objects and applets collaborate together, rather like British common law has jiggled itself into existence over 500 years. There's real fundamental science to be done in coevolutionary assembly as well as money to be made.

Miko: So what you're saying is that to a certain extent you can view a Java library as one of the buttons, and that the existence of many different libraries produces many different combinatoric possibilities, meaning less adjacent space.

You heard the analogy, you're the expert, right? What do you think, Bill?

Bill: Well, if we have all these user interface components for speech and image processing and now I can just assemble the user interface by dragging these paradigms together on the screen, it's random. If it's sufficiently easy, I might discover a new high-quality user interfaces by just playing around. That random experimentation isn't possible when the programming is so incredibly difficult that only a small number of people can do it.

John Gage: So, promiscuity does not guarantee survivability.

Stewart Kaufman: Sexual production yields more diversity and more survivability against environmental change than asexual reproduction. That's the whole reason for sexual reproduction.

John Gage: So The Almanac is in some sense is about population and its expansion.

Bill: These are some molecules that are floating around the cell. I mean, they're not--these are still pretty low-level actors in the whole dance that we're talking about. And we only have one kind of cell; which is kind of this applet framework right now. But, there can be other kinds. We've got the basic exchange mechanism with RMI. So, I think that's most of the mechanism--to create a system where evolution can occur.

John Gage: Where does the added value come from? Is it just by the promise of new niches? Is that the general thrust for the economic development?

You bet. Think of what an airplane is, John. Think of the Wright brothers in their bicycle shop in Dayton. An airplane is in effect a recombination of an air foil, a light gas engine, a couple bicycle wheels, and a propeller. The more goods and services you have in an economy, the more ways there are of hooking them together to find precisely what you just said Bill: new useful combinations.

That's why I think the economic web is growing hyperexponentially and that's what's making what's happening with Java technology so fascinating. You have all these folks here (at the conference) and all of the companies they represent and all of the combinatorial opportunities to sling things together so that the creation of economic niches is expanding very very rapidly, where we can earn a living because we can create value. It's a supercritical economy that we're in, in terms of value creation and diversity creation. Therefore, diversity is driving economic growth, which the economists don't really understand yet I think.

John Gage: So a measure of the super criticality and we are at this the point where a tiny change causes an enormous set of repercussions. The growth of the conference and the growth of the interconnections among everyone....

Right, just a little bit more concentration and a lot of companies are going to precipitate out of the solution.

Miko: I have a question about diversity. You have a very large set of individuals interacting. Is that a stable system? I mean, how does that behave?

I think what's going on, you know, I don't know if you all know about Pier Bakin who conceived the idea of self-organized criticality. Have you run into this? It's a wonderful image. You take a table like the one in front of us and you drop sand on it. The sand piles up and you just keep slowly adding sand until you reach the resting angle of sand. Then you keep adding the sand very gradually and you get slides. And you look at the size distribution of the avalanches of sand slides. You get lots of little ones and a few big ones. So if you plot the size on the X axis and the number on the Y axis, you have the scoop distribution. Take the logarithm of both axes and you get a straight line down to the right. So, it's a power law.

A number of us fell in love with Pier's stuff and began to look at the evolution of the biosphere; for example, species abundance and extinction in speciation events. It's going to tie to technological evolution in a moment, Miko. There's a connection, and a real one.

Over the past 650 million years there's been lots of small extinction events and a few humongous ones. If you plot the size of the extinction events, it's a power law. Like these avalanches, if you plot the lifetime distribution of species it's also a power law. Most species die young but if you make it for a long time.... If you look at an economic system and you look at the lifetime distribution of firms, it's a power law with extinction events. And then there are the same kinds of avalanches of technological evolution, speciation, and extinction. So, when the car came in, it drove out the horse, and the buggy, along with the saddlery, the smith, and the Pony Express, but paved the way for paved roads, an oil industry, a gas industry, fast food restaurants, and suburbia.

So, here we have all these avalanches, Miko. And Java technology is an example of an avalanche coming into existence, will trigger lots of economic change because it creates economic value. So, you have Kleiner Perkins helping to filament the revolution by helping to support companies that will come join the Web as it grows. I mean, you're creating an avalanche.

So, we have this web of creation going on very rapidly right in front of us.

Miko: I have a sort of a follow up question, which is that you are now only somewhat interested in Java technology from a perspective of research, but you have a company that is moving to do all of their programming in the Java language. I know that you have some really big customers, like Nasdaq and Boeing and I've heard Honda, so you have very big customers ...

Did I pay you or something Miko?

Miko: No, but I guess what might be interesting to talk about is what do these customers want to know in terms of what complexity adds to their companies?

Stewart Kaufman: Well, the idea is that lots of the computational stuff that we all do turns out to be new tools to think about how an economy works. So, the phase transition and the button and thread story is the emergence of connected clusters.

Nasdaq wants to make agent-based models. They have fascinating problems in that they have market makers and outside buyers and sellers. If they change the microscopic rules of how you buy and sell on their market, for example from going from sixteenths or eighths to pennies, the hope is that you'll narrow the spread so that more money will flow out to customers.

On the other hand, maybe you introduce instability in your market and you get higher volatility. They have no way of assessing that. So, the idea is to make microscopic models of agent-based models of people involved in the market, and look for emergent phenomena, including how you beat the market. So, Nasdaq sends out the Nasdaq police to look at how people are beating the system and other such things. Could you use an agent-based model possibly to foretell unforeseen consequences? And if we could, by the way, then Bill, we could come back and try to predict some of the directions for which people will use objects to create your higher level objects.

Miko: How about with Boeing?

Stewart Kaufman: Oh, Boeing has the following problem and I think this is not confidential. In fact it is obviously public. They want to keep their airplanes in the air.

laughter

I don't think I'm saying anything harmful to Boeing. They've got the following problem. It takes them five years to design an airplane and get the first two constructed. They want to understand how to make airplanes that will be a family of aircraft for niche marketing, and cut the design time down to, for example a year. Now, if they could do that, it would be spectacular. But this confronts them with the following kinds of problems.

What are the right modular parts? This is interesting Bill. It's similar to Java technology? What are the right modular parts out of which you can make a family of aircraft reliably? If you have the wrong modular parts to build it, you won't be able to do so. So, we're trying to look into the notion of technology grafts. Namely, if you had a set of fundamental building blocks, what objects can you make from them reliably and flexibly, which is very much like what you can make with Java objects, and what they can become. So we're trying to develop some new science for that.

Meanwhile, they have the optimization problem, of trying to optimize over four or five fitness functions, like your airplane has to be able to land on a short run way, or carry 17,000 people, or whatever your set of criteria are over a configuration space. The configuration space gives you a hard optimization problem for each of your criteria. You have multiple criteria. The solution is an optimal set. How are they distributed in the configuration space? How can you surf your way around in that space and find your way to a solution?

Bill Joy: This does suggest some of the higher-level tools.

One of the things as we're putting together a very large application and you have a number of abstractions which had--this interacting abstractions, you may have to pick implementations of those abstractions that are of appropriate scale for your problem. So, there is an optimization problem, and just picking from a set of possible implementations that's something we just don't.... Data structural selection has been talked about for years and never done because we didn't have a language where we could actually do it.

John Gage: We have to have a base. You were emphasizing testing, testing as the next frontier. If we're going to put so much software in small devices, if I'm on these Boeing planes and somebody's been fiddling with optimizing different parts, I'd like to feel that there's an objective function as a test component in the overall design.

The thing is too that essentially, you can only test the specification. And so one of the biggest problems is the difficulty in specifying what you're supposed to be testing. And if you can simulate a semiformal specification, then you can generate some of the tests automatically. And that's essentially what the hardware people do. In fact they simulate at many levels, it's not just at the circuit level. They'll do an instant analog-level simulation, they'll do some gate-level simulation, and they'll do some register-level simulations only because simulating everything at the electron level would take forever. You've got to establish a hierarchy of simulations.

John Gage: So we do it's the 'phanto'second, nanosecond, the different levels of interaction so that there are natural scales at which you apply the proper design criteria, but they are different.

Stewart Kaufman: Yeah, it's shocking that we don't have many many buildings full of computers that are testing the quality of our software all the time before we ship it.

Boeing certainly has run the rooms full of machines that are simulating models of their planes to make sure that all the mechanical things...., because that's the reason their planes are reliable. The average software is a joke by comparison.

multiple voices How much of a joke?

How many programs have crashed on you today?

John Gage: Windows95.

Stewart Kaufman: Yes, I want to reboot my system now.

Miko: So, I guess what I'm hearing to a certain extent is that if we can solve some of these critical testing issues and create the stability that all of these new interconnected buttons will go into this log phase. And things will start to take off in terms of Java interconnectivity.

Stewart Kaufman: Well, and that's the question. I mean, it's easy when you just have a pencil to draw a line from point A to point B, but if it involves two conceptual things being able to work together, if that it involves people, it involves politics, it involves some technical issues that we understand what to do when we have a speech and an image on the screen at the same time. You know, this understanding of putting those things together in a useful way. And we have to get enough understanding that we can start connecting the large areas of knowledge together.

Yeah, that's right. And I think there is no short cut to the fact that it's just going to be really hard intellectual work. None of this is a done deal yet. But, that's fun, so one works hard.

John Gage: Stewart, you mentioned the research program in the Java Developer's Almanac is an inventory of industrial objects. There are mouse objects. So, when the Generation X consumer says, "I expect to do with a click of the mouse," it could be something which in reality will not be a click of the mouse, it might be a tensing of an eye muscle or a shift of human attention, or a lift of an eyebrow. We have those older objects in bed. They're defined here as best we could and intellectually we've separated them as cleanly as we could. But, the metaphors of what will we be using and how will we interact are still in this process of development. So how do you build a research program that gives you an idea of direction? We can get any sense of what needs work and what doesn't.

Stewart Kaufman: I have some beginning thoughts. One of them is just to look at the Java network as it's growing. What are in fact the complements and substitutes that we're all doing? How do things actually fit together in detail? I mean, with actual connotative detail about why does this create value with that. And roughly speaking this collectivity can do this. We can actually gather the data and have the first case of what an economic web looks like. If we do it so that we have sort of the morphs, how the things come together and create value, that may help suggest both the structure of a web and its growing points. It's what the young ladies were telling us about.

But, John there is another thing that struck me when you were telling me about The Almanac yesterday. If I'm a good chemist--and I'm not--but, if I were a good chemist, and you gave me a pot full of organic molecules, I could predict what next molecules could be made next out of the ones that are around. Therefore, I could look at the unfolding potential chemical graph in front of me. It seems to me that one of the fascinating things to play with is, if you think of objects as: 'is a,' 'has a,' 'does a,' 'uses a,' 'needs a,' there's a kind of generative grammar already implicit in the objects. What does it imply about the generation of new kinds of objects that will become, Bill, your higher-level entities?

Bill Joy: Like, on an asic with a bunch of objects inside with a new pin out that's much more useful because it's simpler to use. It's like putting a cell wall around a collection of objects.

Stewart Kaufman: Yes, and then one could actually try to look at what it would mean for such things to coevolve, sort of jiggling together into existence like British common law did.

Bill Joy: They need the driver for the co-evolutionary process.

Maybe do random mutations. We write "bloaty" code then it will be easier to evolve it, is that right? It's more likely to work. A single mutation is likely to still have a program that works.

Stewart Kaufman: Well, we need something that's the criterion for usefulness on the other side, you know. Which is just your point.

Bill Joy: Doesn't crash.

Stewart Kaufman: Well, that's a minimum criteria.

Bill Joy: That's generally the way most of the mutations get rejected that is if the program doesn't compile.

Yeah.

John Gage: Well, we're moving.... Can you just check off the "it just works" option? That's the one we're after. Our value is diminishing as we go past the time allotted to us. So, I'd like to thank the panel. So, are there any last thoughts about directions. Bill, do you have an idea?

Oh, I should mention this.... One of Stewart's newest companies, the Bios Group--there's some orange colored papers that are surveys about what are you doing. If you don't want to fill this out, go to the web site, which is www.biosgroup.com/java and you can answer some questions that might give Stewart the beginning of some data to see how is this 'Schumpertarian' avalanche of creative destruction. That's our new T-shirt. Java technology, avalanche of creative destruction.

multiple voices

And Bill, you can talk about punctuated equilibrium, but not now. Thank you very much. Have a great day today; keep the energy levels up; and meet ten people today!

applause