Transcript of the Tim Berners-Lee Leynote Session at JavaOne.
Delivered May 31, 1996 at Moscone Center, San Francisco, California.
Tim Berners-Lee, Director, World Wide Web Corsortium, Laboratory for Computer
Science at the Massachusetts Institute of Technology
Presentation entitled, "The Axes of Revolution"
With opening and closing comments by JavaOne host, John Gage, Director,
Science Office, Sun Microsystems(tm), Inc.
Gage (Host):
Well, everybody's very wide awake, and I want to do something-you're going
to think I'm dumb, but I want to do this anyhow. Remember the first day
I said, this conference, JavaOne, has somewhat the feel of the first Web
Conference where you're meeting people that you'll work with for the next
ten or twenty years. You're meeting the people that are going to make, with
you, the new companies and the new products.
So here's my dumb idea. I want everybody to stand up, and you're going to
look to your left-it's like a religious event-you're going to look to your
left and your right and behind you, shake somebody's hand you don't know.
Alright, we're going to do this, because it's going to overcome all inhibitions.
Alright, everybody up. Alright, now shake somebody's hand you don't know.
Give them a business card.
[For several minutes people in the audience stand up, talk to each other,
shake hands, and exchange business cards.]
Alright, I don't see enough cards being exchanged here. Exchange those cards.
Great.
We have until 4:30 today, so everybody has to take as much advantage as
they can of propinquity. I'm a firm believer in serendipity. Somehow, you're
probably going to end up working with someone you just met, and you just
don't know it. Because you all had the good sense to sit in the same area
that means there's a personality trait you share. Now for Curt Jans, Chip
Webb, Vince Hodge and the entire Mitsubishi crew, and all the other people
that ported the Java Virtual Machine to a device; we've got your blood red
ribbons. So these are for all you who are porters. I think these people
should also get hugs as well as all the authors.
The logistics today... [Speaker continues with details of the day's
schedule] Now talking of BOFs, or Birds of a Feather meetings, there's
one special BOF, I want to tell you about, and that's "Arthur van BOF,"
and that's for Arthur van Hoff. For those of you that don't know Arthur,
let me tell you about the role he played in the development of Java.
You've all been in those engineering meetings where things have gone on
for a long time; and the last two people who said anything have matched
their vehemence and their length precisely proportionally to their lack
of understanding of the problem. You're bored-you're at that moment where
the meeting is falling apart, and it's clear nothing can really be made
out of all that time spent talking. Well, that would be the moment when
Arthur, with Guy Steele, Bill Joy, James Gosling, and all the group deciding
and voting on each aspect of the language, Arthur would say the mantra of
the design group: "If you're going to do it, do it right." And
that led to each of the simplifying decisions in the language design. Each
time some element from Scheme, Oberon, Beta, or the Simula 67 follow- on,
each time a language element came up that would add complexity, new performance,
or new capabilities; Arthur would always say, "If you're going to do
it, do it right." So that maxim has to stay with all the work we do.
And there's a second maxim. Avoid gratuitous difference, because we're aiming
for ubiquity. And that little demon-that little Steve Jobs that lives in
all of us-"I can't make money unless I make it different," you
know, you've got to bat that demon down. We're trying to build something
so that it's ubiquity on the bottom, and innovation up above.
Those are the maxims; those are the primary things I think we need to pay
attention to. When you get that tome, the Guy Steele/Bill Joy book-I was
looking at this last night-when you get to the dreaded Chapter 18, which
is the LALR1 grammar and syntax-the part you always skipped in computer
science courses, the part where you fell asleep-that's what James referred
to as the serious analysis at the bottom revealing things we didn't think
about before; exception cases that no one thought of. When Kahn pointed
out some floating point exception problems that no one had considered, there
were language changes.
So we're soliciting from you now at the end of this conference, every thought
you ever had about how the language can be improved, and also how the conference
can be improved, because we're going to do it again. So please tell us what
you think-changes in the language, what should we do, how the next conference
could be improved, and send anything you have to say to us to: JavaOne.comments@Java.Sun.com.
For those of you that want audio tapes, you know you can get them. Everything
was audiotaped. Many people have asked me about videotapes. The keynotes,
and we think all the Technical Tracks, were videotaped. Do you want those
tapes? We hadn't planned on selling them; but if you want them, we can dupe
them off again, JavaOne.comments@Java.Sun.com, tell us what
you think.
The transcripts for all of the talks, the keynote talks and the Technical
Track talks, are being put up on the Web site, grammatical flaws and all.
[Note: Technical Track transcripts will be published later.] So
you'll be able to track things and be able to recreate those moments when
you sat here. I must say, and I hope you agree, that the technical level
of this conference has surpassed my best expectations. I think these have
been extremely powerful talks.
The next thing I want to tell you about is ubiquity. Now the point I brought
up about avoiding gratuitous difference comes to this design criterion of
simplicity, and Tim Berners-Lee had the good taste to solve the high energy
physics community's problems about communication. He had the good taste
to weave together existing metaphors and existing protocols into a way of
thinking about reading and writing that seemed obvious and clear. That's
the genius of it. So to describe how he thought about that, and what lessons
he's learned as a result of the explosion of the Web, the first revolution,
here is Tim Berners-Lee.
Berners-Lee:
Well, it's incredible to be here in this exciting environment. A revolution
is always exciting. It seems to me it was only a short while ago that we
had the last revolution. In fact, the Web Conference in Boston was subtitled
"The Web Revolution," and that was in December, and here we are
with the Java Revolution. The revolutions are coming closer, and this is
not just coincidence. I think they'll continue to come closer and closer.
And that's one of the themes I'm going to talk about.
And the other thing I'm going to say, and John has just said it, is "Get
it right." If I've got one thing to say to 6,000 people sitting down
at this stage in a revolution, it's "Get it right for the future."
I'm going to start off the thinking about this revolution with a comment
that was made by Bob Beckhoff at the World Wide Web Conference in Boston,
when he wound up-I must admit, in a slightly cynical conference-winding-up
keynote; nothing like the keynote that I'm giving right now, which is of
course going to be terribly positive and enthusiastic-he said, "Well,
guys, you know, what is this Java stuff anyway? Hey, it's just another computing
language." And everybody laughed. And then perhaps, as people went
away, they thought: "So what is it?" And it's a lot of things.
We're celebrating a lot of things today. There are lots of different angles.
There are a lot of different axes.
I should point out, by the way, the importance of multimedia. These are
axes of revolution. If you thought it was axis in the sense of hatchets,
then go back and see your shrink, if that's the way you interpreted it.
Yeah, it's just another language. But it's a good one. We've had languages.
We've had good languages. Well, come along, we've had Eiffel and Small Talk
and lots of really interesting languages, but the nice thing about this
one is that we're allowed to use it, we're allowed to use it because the
time is right for a revolution. Java is sweeping across the world so that
if you go to your boss and say, "I'll think I'll write it in Java,"
then your boss will be very impressed and she won't tell you, "Don't
be silly; we don't program like that here."
And so if there's one thing that you can get out of all this, without all
the other things, it's that we now have an excuse to really use object-oriented
programming. I find it kind of interesting that object-oriented programming
became viable when it went global. Hypertext was around a long time before
the World Wide Web, but when those Hypertext links could only point somewhere
on your local disk, it just wasn't very exciting. Making it go global with
the Web, suddenly made it very exciting. Object-oriented programming in
a global environment is suddenly very exciting when you can inherit from
something miles and miles away written by someone you don't know, from whom
you've only just found the documentation, but whose home page you've read.
That just increases the power of it so much more. I wonder whether this
will happen to other things as well? I'm interested, for example, in knowledge
representation languages. Maybe we'll have knowledge representation on the
Web. Maybe we'll have the great big brain, the great big Web of knowledge
in which computers can wander around and make conclusions. That'll be another
exciting thing. So maybe we'll see a few things which, given the magic dust
of global space, become really exciting.
So yeah, if you count it as just another language, then Java is great just
from that point of view. It's great to have a good, well-thought-out language.
We're celebrating also the idea of putting things in small environments.
Java was designed originally not for zooming around the place at high speed,
but for being put in a small environment without necessarily the overhead
of an operating system; and it was designed to get over that portability
problem. And then it was produced as mobile code on the Web. That's how
it's been rolled out. I mean, Oak was there for a long time before Java
applets suddenly started to turn up. Now, if you ask me, Java applets are
a fairly arbitrary application of Java. There are lots of other things that
are really exciting about Java apart from applets, and lots of them have
been talked about.
And if you're going to talk about this as a revolution; a revolution has
got to leave the world with a totally different view of itself from the
way it started. It's got to be a paradigm shift. So where are we going to
be? When this revolution is passed, what's it going to be like? I'm going
to look at some scenarios. What are the software architecture and computers
going to look like, assuming that we get to globally distributed computing.
So there are lots of different components to this.
One of the aspects of getting it right that I can't say often enough is
keeping things independent where they can be independent. We've got a lot
of things here. We've got a programming language, but it's not just another
programming language. We've got a bytecode. From the point of view of somebody
really interested in interoperability between machines, what goes across
the wire between two machines is a very important standard. Yes, in fact,
there are lots of standards included in it. When you send some Java bytecode
across the standard you're using, it's not just a standard for the Java
bytecode, for the virtual machine that it expects, it's also for all the
APIs that code will expect. So effectively there are a lot of standards
involved in that message. There has to be a lot of common practice between
those two sides, which you have to have agreed on for this thing to work
interoperably.
So we've got the class libraries, which a piece of mobile code finds when
it's arrived. We've got a class loader which is a very important part of
the system, and it seems to me that the algorithms the class loader uses
might determine the whole shape of the future. They may change the whole
political and social topology of the Web after the Java revolution.
There's remote method invocation. Well, I've always been a great fan of
remote method invocation, or IPC. In fact, before I did the Web, I had a
little remote procedure call project whose goals were rather Web-like, and
the idea was that anything running on any machine in any language ought
to be able to call anything else running on any other machine in any other
language. One of the nice things about doing remote method invocation is
that you have the ability to cross between all kinds of boundaries, and
in particular language boundaries. So if we have a remote method invocation
system that allows you to call a Java method, a remote Java class from a
Java object, and it assumes that both ends are Java, then it's kind of worrying.
We've got a great flexibility point there.
Isn't it rather important that we go to the effort of making sure that whatever
we use from our procedure call-whether it is CORBA-like and Java has been
attached to it, or whether it is remote method invocation that has been
extended so that it can encompass anything anybody would want to do in another
language, with as much overlap and match as possible-when we've done that,
the way we do a remote invocation is separate from the programming language
we choose. It's clear that the programming language we choose -- I mean,
Java is a great programming language, and the title of this is the "JavaOne
Conference"-- Java is the name of it. But there are lots of other things
you can put into Java bytecode. And in a way, the importance of the architecture
is also in that bytecode; and is anybody going to object if a particular
bunch of people, who for some strange religious conviction or other, really
like programming in Cobol? If you want to compile that Cobol down to Java
bytecode and send it across the Net; then, no, nobody's going to object.
That's fine. We've got a great flexibility point there, so we've got flexibility
between the programming language and the bytecode, and that's very interesting.
It might even be interesting, if necessary, to look at putting a few extra
things in the bytecode if that meant one could support other programming
languages more easily, more efficiently.
And we're not just doing this because of the legacy things. When the Web
started, there was the same question. There were the URIs, the universal
resource identifiers-well, they're called locators now, but that's a long
historical question-but the original idea with these URIs, call them URLs,
was they could be any address space, and you've seen FTP and Gopher and
News URLs as well as HGDP URLs. Now that was not just an attempt to simply
get the legacy data in there, and bootstrap the thing by allowing you to
get it all out of FTP space, which is, of course, an important part of it.
But, the assumption was-and it's an unproven assumption, but it seems good
to me-that if you can make a system that is sufficiently general to encompass
the previous things, as well as your latest and greatest, then maybe there
is a hope that you will be able to keep that system for other greater things
to come, that somehow you've given it flexibility along that axis, which
you can project into the future.
So that is the more important reason for keeping these flexibility points;
for making your RPC, your remote method invocation system language independent,
for making the bytecode and the programming languages as independent as
they can be, making the APIs callable from other languages. Now I know that's
not simple. I know that when you have garbage collection and everything,
it is very tempting to just rewrite all the APIs, and in a large number
of cases it's a great idea to. But, in the spirit of keeping the APIs, as
John said, with no arbitrary difference, don't put in an arbitrary reason
why one of these things is connected to the others, and can't be disentangled,
because later, you know, there will be other programming languages. Java
may run for 25 solid years; I don't know, Java may have a longer run than
Fortran and C. Or it may be that in seven years' time, somebody comes out
with something that is just a whole different paradigm. Maybe somebody finds
a way of helping a user program graphically, and the result has a different
structure. And so hopefully whatever comes out of that will still go into
the bytecode. It'll still be able to use the class libraries and you'll
be able to interwork remotely or locally. Frankly, the fact that remote
method invocation allows you to move between different processes, different
processors, different architectures, hardware, and software in different
languages, is in a way more important than the fact that it allows you to
go remotely. Architecturally it's really important. So that is one thing
that I am saying to anybody involved in the design of all these things.
Let's try and keep them independent.
I'm going to assume a few things about the future. I was thinking and wondering
as I came out here on the plane. So I'm going to give you the wonderings
I had on the plane about where this is all going to end up; and what the
software that 's actually going to be sitting on one of these computers
is going to be.
So first of all, let me state without argument or discussion what my assumptions
are. I'm going to assume that this crazy situation we have at the moment,
where you have all this space, and that you have a thousand pixels by a
thousand pixels representing your virtual desktop, and that somewhere in
the middle of it you have a window representing the whole wide world, that
all that is going to have disappeared. When you look at the screen, there
won't be a difference between the desktop and the browsers. There will be
an information space out there; the hypertext paradigm will be there; and
the dragging and dropping little icons paradigms will be there, and they
are pretty mixed up. There's not really a lot of difference between a Hypertext
document and a desktop the moment you start writing on the desktop.
So I'm assuming that we have a very consistent user interface. I'm assuming
also that just as the Web allows people who don't really want to know about
computers to browse around, and hopefully to edit, and to communicate, and
work together with people without having to worry about host names, cables,
routers and things. I'm assuming that that will continue, and when you look
at a computer, you'll see less of the computer. For example, you won't have
to keep thinking of file names. The file space will be less visible. You'll
just create information, say what you want to do with it, whether it's important,
whether you want it to be kept, who you want to know about it. You'll simply
be making associations and links.
So let's assume that the user interface is very consistent, but then when
you look at a computer, my feeling is there's going to be a whole bunch
of different sorts of computers, that all the questions about are we going
to end up browsing the Web on our television or on our computer? Hey, they're
going to be the same thing. It's just a question of whether you buy it from
the television company or whether you buy it from the computer company,
which may be interesting if you're a television company or a computer company.
But, basically, the thing that you will see will be the screen, the user
interface, the gloves you put on, and those things will effectively define
what you see as the computer. So I expect that they will be defined very
much by the screen size and the bandwidth, and that will define all the
other things.
So, in my living room I expect to have a big screen; and in the kitchen
I expect to have a much smaller one that I expect to be able to pick up
and carry around with me; and in my pocket I expect to have an even smaller
one. But basically I expect, when I pick this thing up, I'll open it up,
and the information space that I'm provided with there is all part of the
same space, and I'll feel quite comfortable. The difference between these
is going to be the bandwidth, and that is going to fundamentally change
the sort of hardware these devices are going to have.
So the one I pick up and carry around from the kitchen for example, is going
to be communicating by radio. It may not have a very fast link. It will
be going at 900 megahertz into my local radio LAN in my house. It will probably
have a disk on it, because it may want to cache things, because it may want
to run faster than I can really happily run across that local LAN. So the
software architecture in there and the hardware architecture may have different
bits of infrastructure, but the effect will be the same. And of course I
won't really expect to watch video on something that I pull out of my pocket
if it's got a low bandwidth connection. If I'm out of the house, for example,
it has to go cellular, but I won't expect to get the latest movie over the
cellular.
So there's going to be a whole variety of different sorts of computers,
and if you want to call one of those a network computer, go ahead-I don't
mind-you can call whatever you like a network computer.
I'm going to make another assumption. I'm going to assume that as you're
browsing around this information space, as you come across all sorts of
things, that we have a general rule: whenever you come across something,
no matter what it is, no matter how weird it is, or how simple it is, if
you don't have the code that it takes to support it, to manipulate it, to
edit it, look at it, display it on the screen, book it, reserve it, taste
it, whatever it is, then you can go get that code somehow from somewhere
in Java. You can download it so that every single object is supported by
Java. Let's assume we take that to the limit.
I'm also assuming that Java classes are first class objects. There's a little
worrying note I have that there's a namespace out there for Java classes
and it's not an URL space, but it's a different namespace. Whereas in the
Web, we have this rule that if you have a namespace or an address space,
if it's a good one, then you think of a prefix for it, and you put the prefix
and the colon on "my new namespace:-MNSP:" and then you can put
whatever you like after it. And so we like to assume that everything about
the system, the Java classes, objects that define everything about them,
where you can get implementations and everything you can find out there,
are listed like everything else.
In a way, we've got a lot of different things at the moment. We're used
to having helper applications and plug-ins. Now we've got Java applets.
We also, in some cases, have remote procedure call stubs, remote method
invocation stubs. We have some things that are big and sort of autonomous
and sort of rather evident that put menus up, which we call applications.
And we have things that we think of as parts for the operating system. But
I'm just assuming that you'll pick up any of those things. Or basically
when you pick a piece of support code, you may get something, which in 1996
you might call an application, or you may get an RPC stub. But the whole
world will be consistent. Can I assume that, you guys? Can we make it consistent?
Good.
The class loader becomes a crucial thing, as I've mentioned. I'm assuming
it's loading everything recursively, and let's just assume now that the
security problem is solved, okay? When the class loader finds a piece of
code, it's signed, and along with the signature there's a URL pointing to
the certificate for the person who signed it, and when you read that signature,
it's signed, too. And there are some URLs you can follow up to other certificates,
which justify the key that somebody has. And you can follow through, and
your class loader, or the operating system, whatever it is, the basics,
the guts of this thing, can follow through out on the Web. It can retrieve
things, because all these certificates are also first class objects. You
can access them. You can query them. You can check who wrote them.
And so the class loader connects securely and it can pick up things that
you trust. It also understands licensing, because the statements people
make in security at the moment are very simple. But if you look at the licensing
statement you get on the back of a shrink-wrap package, it's this long.
And if you look at the licensing you get on say a train ticket or a plane
ticket or something, you find that in fact you can get air miles if you
go to these hotels; if you travel mid-week and you don't stay over Saturday
you can get discount or you can't get a discount. In fact, things are very
complicated. And I imagine that the licensing of things you load, could
be quite complicated as well. So your loader has got to be able to understand
that it doesn't have to pay with your credit card to get this business software,
because in fact you've got a site license for something that is not the
same implementation, but it's guaranteed to be equivalent by somebody you
trust. Things like that.
So the class loader is quite a healthy and complex beast. And it has to
decide among different versions of things. We're going to have different
versions of things that we really depend on, being brought out. And when
we have a lot of software on there, the configuration control problem is
something that people find very difficult to handle, even when they're given
weeks to think about how to reconfigure a computer. The class loader of
the future is going to have to solve this in a twinkling. It's going to
have to decide, alright, well, this one wants me to upgrade this module
right in the middle of my middleware. It needs to be upgraded. That will,
if I upgrade to this, cause incompatibility here, which will mean that I
will have to swap out that, and that, and that, which will cost me this
much hard work, effort, dollars, time and delay for the user, whereas if
I just wipe that out and drop that back to the previous version, we can
run with what we have as a window manager and we'll be okay.
Now all these things are pretty horrific at the moment, and it's going to
get a whole lot worse when it's so easy to pick up more software to clutter
your computer with. These are the assumptions. So, given those assumptions,
what are various scenarios? What's going to be happening on my machine?
Here's the first scenario. Basically, all this downloading stuff is alright,
it's very nice, but in practice users find they like to okay large downloads.
They don't mind little applets, but when they get things that remain resident,
have more power, that in fact it works out because of the way it's been
designed, and the way human beings are they want to okay things. So large
amounts of code don't get moved down very rapidly. So the content providers
feel that they can't expect users to have a lot of this middleware stuff,
which is above the operating stuff, but below the application. So content
providers tend to really prefer to provide content in terms of that which
is in the operating system, which puts a lot of pressure for every new thing
to be put into the operating system. Bill Gates said the other day of Microsoft,
"Yes we work with research. Our research people produce lots of great
ideas, and of course we are very excited to watch what they produce, and
the moment we see from the research community interesting things come out,
then we incorporate them into the operating system."
So it will go on like that. All major advances have to really become part
of the operating system before you trust it. You know, it was a bit like
this with TCP. But you could get TCP for VAX/VMS machines, but I don't know
whether people already thought it was trustworthy until it came from the
original manufacturer of the operating system. So maybe it's been the same
with TCP and Windows. People feel happier once it's in the operating system,
because there's a trust boundary there.
So the pace of innovation is limited by the pace you can get things into
the operating system, which tends to be limited by the how fast you can
make it a serious threat to that operating system that otherwise it will
be damaged by people doing it other ways and inconsistent ways. That is
scenario one. You may recognize quite a lot of that scenario one.
Scenario two isn't very different. Scenario two says; hey, we don't need
that operating system because every month we're going to be rolling out
10, 15 new Java APIs, and these are going to cover everything for security
and payment; and hey, there's going to be a file system coming out in a
couple of months, and you're already got the Windows manager, what else
is there?
So bit by bit the new Java classes-they're brought out so that you can run
Java applications and Java applets in a lightweight environment where you
don't need a heavy operating system pretty soon-are replacing the operating
system. You really don't need the operating system. This is great. You have
operating system portability. You can run on any operating system. All you
need is Java. And you can get Java with full disk tape support. You can
get the Java operating system to run on your mainframe. In fact-although
the lure of it is the lightweight side, and although it still works for
the lightweight side-pretty soon you get all the things that are fairly
heavyweight, and all the lightweight machines get bigger; and these little
machines start getting enormous quantities of memory. So pretty soon, just
as we see new PCs picking up all you need to become a mainframe, you'll
find the lightweight Java environment picking up everything else you need
to become an operating system, and this may be a reasonable way to go. You
know, maybe it will be a better operating system. Maybe, for example, if
we do the security right, it will be a secure operating system. Maybe there
will be a few things that we can look back on and say, well, there was some
work done on secure operating systems way back when, but it never really
took off. Maybe this is another thing we ought to go back and do right now.
And so we will end up with an operating system perhaps with a different
name. It will be called some sort of secure network distributed computing
environment, but it's going to be an operating system, and it may be a better
one, so maybe this will be a good thing. Or maybe it will just be another
operating system. Maybe it will just tie everybody down, because it would
end up being totally monolithic.
What's another scenario then? Break out of this monolithic operating system
business. Just download. So suppose you accept pretty much everything out
there. They do right now. You know, you can put all kinds of stuff on Web
pages. You can download things and the browsers don't generally ask you
very much. They ask you a lot of questions, but you can always check that
little box that says "Please don't ask me again, because I do not understand
the question." So then with legal impunity, you go ahead and download
all kinds of stuff.
So we don't have to rely on the operating system at all. No-in fact, I mean,
pick up my slides. They're out there. They're on the Web. No, they're not
in HTML? Actually, I developed them in my own special version of Harvard
Graphics, which runs on a Mac. But it's okay, because if you've got Java,
you can do it. What happens? You click on it, and you don't have Harvard
Graphics. This is a Mac version, but it doesn't matter, because you recursively
download a Mac emulator, and you are running a complete Macintosh emulation
inside your browser or in your Java machine-in your space somewhere you've
got a Mac. You might notice that the windows have got these funny little
black boxes, whereas before they had gray boxes, but apart from that it
doesn't phase you too much. And you notice also that the memory meter on
your machine is getting really near the red end of the scale, so you remember
to go out and buy some more memory.
You might also be noticing with these new sites, there's a little thing
that says you can browse this site; this Time Warner site, but please don't
do it; it's best browsed with browsers that haven't been browsing the Disney
site recently. Because if you browse the Disney site, you download a whole
lot of stuff that will clutter up your disk. Don't do it. What you need
to do is to bring down our animations machinery, our high speed video, and
you really need all the space the have. You notice that if you start switching
between those two sites, well, fortunately between those two sites, there
may not be a lot of hypertext links. But if you're browsing between people
who talk to each other, and communicate with each other and you find yourself
switching between one person who's drawn a graph on the Macintosh, and one
person who's drawn a graph on a PC, and you're comparing these two graphs
on the screen, you may find you just have to have a PC and a Macintosh in
there, and the whole stack. In fact, if you look closely, you may find you've
got an Apple II, and a couple of varieties of Mac, and a Quadra, which have
been brought in for various different parts of the applications you've got.
So there's an explosion in the amount of memory you need, and the amount
of virtual memory you need. You find that the thing keeps paging out. You
think that the Web site is slow. It's not slow. It's because you're paging
in and out all this software over your radio LAN into the cache in your
basement. Hang on. This is not up for discussion. That's part of the assumptions,
okay, that you have a radio LAN and you have a big cache in the basement.
The network computer definition starts at 64 megabytes and 10 gigabytes
of disk if you're really going to be able to read your local paper.
In this free-for-all, something else that struck me on the plane, is that
part of the Web community were kind of horrified when they saw the first
advertisement on the Web. In fact, the first advertisements on the Web happened
very early on with people's selfadvertising home pages saying how wonderful
they were. And it happened before that, when people put academic papers
up saying effectively how wonderful their projects were. But then when people
saw advertisements-they're reading a page about one thing and then there's
this little banner about something totally different-they think, "Wait
a moment. I followed a link to get this, and I'm getting something that
is different. That's not on my agenda. That's part of somebody else's agenda."
Now that upsets some people, but most people said, "Yeah, this is advertising;
I recognize this; this is fine." And so we download things.
Another set of people were upset when they hit a search engine and they
found a very large number of times that the top few things on the search
engine were not the things that contained the keyword. They weren't even
the things that they felt were most relevant to the things they'd asked
for. And they found out by talking to people in the corridors that in fact
the people who run the site, who came up top of the search engine had paid
enormous quantities of money to come up top of the list, even though the
rating scale, they thought, was a statistical rating scale down the sites.
They thought, "Oh well. I thought these search engines were sort of
statistically based and all that. But alright, this is the commercial world.
This is fine."
But people are a little bit sensitive to things that come over in the content.
They're sensitive to the quality and whether the content is actually what
it says it is. Now, if you're sensitive to that in text, boy, are you going
to be sensitive to it in code. Now I can see in this free-for-all environment
that there are lots of things you're going to want to put in your code.
In fact, if anything now, there's a desperate, desperate, desperate urge,
"Please link to my site, because I need readership, I need readership,
please tell your friends about my site. Please put a link to it. I'll pay
good money. I'll put a link to your site." It's readership, readership,
readership; everybody needs readership, because they want you to download
their data.
But it may be much worse when they want you to download that code, because
that code can do all sorts of things. That code can do a little bit of tracking
here and there. That code can help you. That code can help you by coming
to a better understanding of your needs. It can help you, it can watch your
keystrokes. By watching your keystrokes, out of a little long running window
that sits off the screen it can start to flash the odd subliminal message
to keep you calm, and cool, and oriented toward the right soft drink company.
And it can, by caching your keystrokes, find out what you need, what sort
of things you like, and that means that it will be able to give you very
much better service in the future. Besides, you have been targeted. They
know who you are. Marketing will be very, very, very much more efficient
in the future. And somebody's making a lot of money by sending your information,
and you haven't figured out how to do it.
But clearly there are things that are way over the edge, and some things
which are totally reasonable. And somewhere in the middle, there's going
to be some line of implementation ethics. Maybe we're going to have to draw
that, just as we're talking about ethics with data, we're going to have
to think about what is something allowed to do. When it says it implements
and interfaces, yeah; this implementation implements this interface; it's
a valid implementation of this class, and also on Thursdays it sends an
entire copy of your hard disk to a given IP address. But it matches the
specs in every way. But there's this question, "What else does it do?"
The free-for-all is going to be interesting. It's going to be a "wild
west" environment. The problem is the mess it makes of your software
when you end up with an architectural chaos on your system.
Scenario four is a loader that is so smart that it's working for you; it
knows what you like, and it knows what you don't like. It knows how much
memory you have and it will optimize. Before loading things, it will check
recursively what they need, and when it has two different versions of something
that it could load, it will recursively check what their requirements are;
and if, for example, it can use one which happens to use the windows system
you've got in, and the class libraries you've got in and therefore will
run efficiently, it will use that instead of loading emulators for everything
else.
So the loader is on your side and it does a great job. In fact, the result
is that the actual swapped-in memory size of a computer you use for doing
your daily work shrinks, because all those bits of the operating system
you don't need, they can be swapped out; all you need are the little bits
of Java that help you use the objects you currently have on the screen.
Right? So the memory size shrinks. This means you can buy more computers
for the same amount of money and that the whole thing is even more ubiquitous
and the code is signed.
We have this web of trust set up so that once you've told your computer
initially who it is, or you've told your smartcard who it is you trust,
basically you are happy to load anything your brother would load, and then
your computer can figure out what to trust and you don't have to worry about
it again. In fact, the only fixed code in the machine is that which you
need to boot, which is the ability to send and receive IP packets in any
one of 20 different ways, and a whole lot of cryptography.
So that allows anything you might now consider an operating system application
to change slowly. Little pieces of your application can be upgraded. For
example, one day your class loader finds there's a free version that is
as good as something you've been paying money for, so it closes down your
license, gets the money back, and subscribes to the free version, and your
memory size shrinks a little bit, and you're bandwidth goes up a little
bit and you don't even know that it's happened. The innovation speed is
just incredible.
Think about the speeds of revolutions. Before we had the Internet, if you
wanted to get a piece of software, it took maybe a few days. You called
somebody up and they sent you a tape and then you asked the system manager
on the minicomputer to load it. He had to go through an installation sequence.
So it took a few days.
But when the Internet was there, you could do all that in just 15 minutes.
When you wanted to get the first World Wide Web browser, you got a piece
of paper with the FTP instructions, you went to FTP, and you found your
way around the FTP site. You brought it over; you set it executable; you
probably did a couple of other things; there may have been some tarring,
untarring, and uncompressing in there. And in fact, you may have had to
go through an installation period procedure, too. But in the case of, for
example, Mosaic, you didn't. You just had to do that change mode plus x
and then you could go. And for an average person who owned a computer at
that time, that was probably only something like 15 minutes if you include
going down the corridor to find the guy who's got the FTP instructions.
Now once you've got a browser, then this time constant for change, for changing
the software that you've got on your machine has shrunk again. Because now
if you have one browser and you want another browser, it's just click. And
then you have to say, yes, yes, yes. Yes, I do want to install it. Yes,
I don't mind putting it in that directory and yes, go ahead. And you have
it. So that's user interaction with a few clicks.
The Internet revolution was not a revolution. It happened slowly in research
labs. It went out through government labs and the Internet spread relatively
slowly. But because the Internet had spread, the Web could roll out of it
like a great big tide. And that enabled everything, a whole lot of things.
The Internet allowed us to forget about roots; the Web established another
level after it rolled in; and the Java tide is rolling over the Web that
much faster. The next tide is going to roll over the Java tide. It's funny;
these tides don't go out. They all stay in. They accumulate. Frankly, I'm
glad I'm up here because it's going to get pretty wet down there.
So the next revolution is going to happen very, very rapidly. These tides
build up on top of each other. In politics you can have a revolution one
way and then you can have a counter-revolution the other way. But if we
do our revolutions right, they build upon each other. And it's worth thinking
about what we mean by doing the revolutions right. John has said, we want
to do it right. The hope is, the Web, for a few good reasons, could be the
basis for the Java revolution. The fact, for example, that there was no
fixed set; that we didn't use an enum type for describing the type of the
data you're moving over; and the fact that HTTP could move any sort of data.
The fact that URLs could encompass any sort of namespace or protocol, allows,
for example, Java applets to come over and take it over. So Java in the
same way has got to be as clean as it possibly can, so that the next revolution
can sweep across.
So going back over the things that I think are very important: One is to
keep the specifications independent. Let's have RMI separate; let's have
as many things separate from the Java language as possible. Yes, you know
and I know that they're all going to work together, they're all part of
the Java revolution. In the early days, I knew that URLs and HTML and HTTP
working together were going to make the Web. But when it came to going on
the ITF, well I started a URI working group; it was a URL BOF, or a URI
BOF and then it became the URI working group, just to look at URIs separately.
I did that as an attempt to say, look, these things are really independent.
They should stand by themselves. In fact, what happened, I admit, with the
URI working group, was-because most of the people there in those days didn't
understand about the HTTP business and the HTML business-an incredible philosophical
discussion about what these things were for. It went off into some elliptical
comet- like orbit and it came back two years later to exactly the same place
it had started without any progress.
So, yes, it is important to enunciate the total, to show the vision so that
people can understand how these things fit together. So it's in your own
minds, and in writing those specs quietly in the back room that you have
to make sure you're keeping them, as much as possible, faithfully independent.
URI space is probably the most important thing. That's the thing where the
argument was that if you've got a namespace that is different, if you want
to argue that these things should have some sort of naming system behind
them, then fine, go ahead and make a namespace, and we'll give it a prefix.
Once you've got one, we'll put that prefix in front of some encoding, some
ASCII-legible encoding of whatever the strings and text you end up with
are, and we'll accept those. And the earliest browsers had ways to configure
themselves so that if you meet a URL with a strange prefix on it, then you
could go through some proxy, which you don't know about, to use the new
protocol. My assumption was that new protocols could happen very, very quickly.
In fact, you know, we're all working on these new protocols. And they will
come fairly rapidly.
Now, if you look at the class namespace, if Sun.Java, or JavaSoft,
or .foo.bodobas is a class name, and that's a good namespace.
Well, if that's a good namespace, people might ask: "Can I put my ping
image in it, please?" "No, it's just for Java classes." "Oh,
Java classes are different? You mean, they're not first class objects? Oh,
they are first class objects. Everything else is second class objects. Sorry,
oh yeah, they go in the Java namespace. So if you've got a namespace that
only works on one sort of object, then can I put my class in the URL space?
Can I put it in the HTTP space or the FTP space? No?" Why don't we
just have a set of name and address spaces that you can use interchangeably,
and we'll have a set of object types and all these object types we treat
as much the same as possible. Yeah. Cleanliness.
Part of that, by the way, is keeping URLs opaque. I will say at this point-
I can't see you, so I won't ask for a show of hands-but URLs are supposed
to be opaque. In other words, if you're dealing with a URL for somebody
else's data, and you look at it and try to figure out from that URL something
about what sort of an object that is-that is bad. Just imagine that in a
couple of weeks we're going to announce a whole new namespace. It's going
to be just amazing. These names will look like random numbers. They're just
going to be gobbledygook. It's going to be "new namespace colon blahblahblahblah,"
and you won't be able to tell anything, because the whole thing will be
name-defined for something else. Anyway, so there's no way you can tell
what's in there, but you put it into one of the newname retrieval service
clients, and it will tell you within a microsecond exactly where all the
copies of that are.
Suppose we roll that out in a couple of weeks. No promises. In fact, I can
tell we won't. But, just as a thought experiment, imagine that. So if, for
example, you are tempted to say that the URL of the file you retrieve is
found by taking this URL, and appending to it the text of the class name.
Stop! You're putting semantics into the URL. Imagine that the URL was suddenly
a UUID and you started appending the class name to it. That would look pretty
silly, wouldn't it.
So keeping the URLs opaque, that's part of the Tao of the Web; you don't
look inside them, but my goodness, it's been a very difficult fight to stop
people looking inside them. From initial times when everybody assumed that
you should look at the end to see if it was a .GIF that you
should have seen as a GIF image, it's been a fight. But that's one of the
important things. I just mention that in case there's anybody out there
who's not intimately aware of that somewhere in their pituitary gland.
Another good thought experiment is, whenever you're dealing with an object
in relationship with another object, that you think global. Just imagine
that the two parts, instead of being on the same machine; instead of being
written in the same language; in fact, one of those two parts is going to
be taken out, and it's going to be replaced by something written by somebody
from another planet. It's as if you were suddenly going to hook it up to
some transmission coming out of deep space, and you have to remove as much
of the environment as you possibly can.
Think global. Assume that the numbers are going to be really, really ridiculous.
It is worth even though there are places when you think that this will scale
fine; this is great; this 32-bit number will do fine for our addresses.
There were times when people felt the Web scaled absolutely wonderfully
because you could put the information server up, and it had zero affect
on all the other information servers. So the load on your server did not
increase at all as a function of the number of the servers, unlike a database,
where, as more people started using this great big database on the mainframe,
this big centralized documentation system starts to slow down as other people
use it; the Web is great-it scales.
Well, folks, now we know, no, it doesn't scale. It doesn't scale because
the load on your server does go up as a function of the number of people
reading it; and that wasn't initially a problem; and if you had a lot of
people reading it, that was great. But now it is a problem with the serious
scaling we've got. We've redefined what scaling is. So when you look at
that, it is very difficult to actually imagine the numbers, actually imagine
the places where it will have to scale. Imagine that whenever you look at
a hierarchical tree, think, should this be hierarchical or should this just
be a totally disconnected namespace? Should these be just URIs in the global
space? Whenever you think of the relationship between two objects, think
that they may be very, very, very far apart or the other one may be one
of say 10 to the 10 other objects.
I don't know when these rules are going to have to be applied next. You
know, when the next revolution comes, they are going to be applied in even
different ways. But think global. Think boundless. When you've got a revolution
like this, don't think about applets. We're talking about a situation where
the whole content of your machine is going to have a totally different shape
to it, and as a result, the whole society and the whole commercial environment
around it, and all the software could look totally different. And the rules
that we're defining now for the way you load classes, for the way you define
protocols, the way objects talk to each other, are defining what those possibilities
will be.
Thank you very much for listening. I'll just say one thing. Hands up those
in the audience who know what this means? [Screen displays the letters:
K U T G W! ] We've had a big turnover. In the Internet days before
the Web, this meant: "Keep up the good work, guys."
Gage (Host):
Thank you Tim, thank you very much. Tim's given us thought experiments,
and I believe each of you have to write those down, put them on your monitor,
or on the wall so you can see them, and perform those thought experiments
each time you begin designing something new.
I wanted to tell you about a few news items that are relevant to what Tim
said. Today, the United States National Research Council came out with a
report on cryptography, which strongly urges that all existing United States
laws be eliminated that restrict the export of strong cryptography. So though
we are by definition non-political, because we work with computers and are
engineers, there is a movement afoot in the United States, and there are
bills in the Senate that would take this recommendation from the National
Academy of Sciences, the National Research Council, and put it into some
legal format. I spoke with Tsutomu Shimomura yesterday, and he says he believes-after
he and Whit Diffie, and about six people deeply involved in cryptography
met with the power structure in Washington-he believes within a month or
so there'll be a relaxation of a number of these restrictions. It's a major
battle.
So follow that a bit. I think the Web site for the NRC is: www.nrc.org
and that's where the text of the report is, as of this morning. It's in
the New York Times this morning as well.
I have two projects -- small projects. The first affects primarily United
States people. The Educational Testing Service is an organization that provides
tests for kids who take the tests to see if they're smart enough to get
into the universities. The Advanced Placement test in computing has had
as a requirement programming in C++. Now, they were going to put this in
place this next year, which would mean this coming school year for every
high school in the United States, every smart kid would be required to learn
C++ to be able to take the AP test. Because of a bit of turmoil, they've
put it off a year.
So there's discussion. If you believe that the steps we've taken, that the
work we've put into this, as Guy Steele designed a scheme to be a pedagogical
language of clarity and simplicity so people could learn about computing,
if you think we're making that same step with Java, and ubiquity allows
everyone to have access-the head of the committee on this is Mark Stehlik.
You may know him; he's at Carnegie Mellon. And his e-mail address is MJS@CS.CMU.edu.
Perhaps before you do this, go to the www.ets.org; that's the testing people.
Look at their Web pages describing this. But they've moved this to the '98,
'99 school year. There's a little bit of time to talk to them, and with
the stack of pedagogical support books that we talked about, I think we
may be able to make a case that we change something that could in fact have
a severe long term- well, it would waste a lot of people's time.
The second project is built, just as Tim said, on the enormous tide that
came in with the Web, and that lovely phrase of Tim's, "This tide doesn't
go out." What we did in California, and in Korea in the last couple
of months was to use the Web to do something for the schools. We said, with
a few Web pages, "Go out, parents, to your school and wire it. Pull
category five wire from five classrooms and a library to a central point.
Do it on a Saturday" Asking no one's permission, I put up 13,000 Web
pages for 13,000 schools in the state of California, and on March 9th, 100,000
parents, engineers, went to 4,000 schools and wired them. And they keep
going. I was not at all sure it was going to work. We put up an appeal.
"Take charge of your own school and go do it." Well, now we have
50 states that want to do this. Korea decided to do it on May 4th and on
Korea Net Day wired schools throughout Korea. Malaysia is planning it. Singapore
is planning it. Country after country.
So look for these announcements. We put a Web page up: Netday96.com.
I'm going to put up that mapping software you saw yesterday, which is the
ESRI software, so you can see worldwide, the location of every school in
the world, and the color of the dot will show whether it's wired or not,
or whether it has computers, or what it needs. So then we can decide by
seeing what needs to be done. That's it.
So watch these announcements about Net Day '96. In the United States, we've
decided to take the four weekends of October-each state gets to pick one
or two of those weekends. Go organize yourselves. Massachusetts' page is
up; North Carolina's pages are up; Minnesota's pages are up-we'll get all
the pages up in the next couple of weeks. Find a school, volunteer, go do
it. And, I think, if engineers worldwide decide to go out and do something,
nothing can stop them. We're going to make tee-shirts that have a drill
on them, and they'll say, "Parents with drills." That scares all
the school boards, but they go along with it.
Now since we're all software people, probably half of us are useless; but
we can all learn. It's just category five wire, a nickel a foot. Just throw
it over the ceilings, and get the schools wired, and then we'll deal with
the questions about computers and links to the outside world and telecommunication
tariffs. And then we can begin to let this tide Tim talked about reach out
into the places it should reach, which are all the schools where the kids
can just take to this and create new things.
Tim had a wonderful phrase; "We have to design systems that are sufficiently
general to encompass not only the existing protocols and systems, but those
that are to come." And the scenarios-I like the free- for-all scenario,
the market scenario-these scenarios of what's going to come all have, as
a result of his thought experiments, extraordinary, rapid change. So the
boundaries of this room that encompass 5,000 or 6,000 of us now are not
actually there. It encompasses all the kids in all the classrooms in the
world, who are going to be the creators of a number of these new ways of
thinking.
And some of the things Tim said reminded me of phrases about what is a language.
Donald Davidson, the language philosopher who has taught at Berkeley for
many years, would say that a language is not a set of rules. It's not a
structure. It's a theory of passing behavior. That is, you say something
to someone else, and you watch to see how they behave; and it evolves. It
changes constantly because life changes. And the conflicts that ideas in
their clash generate change with it.
So old structures just go away, and new conflicts, and new theories of passing
behavior, how we behave at this moment, evolve. That's what we're building
in this giant soup of namespace and identifiable objects. And Richard Rorty
had a wonderful phrase about Davidson. He said that Davidson has described
to us what language is. It's as if a coral reef has metaphors dying off
into solid structure. New metaphors that are startling in their origin die
off into a permanent, accepted structure that everyone uses. "Sunrise"
is an example in English of an old, inaccurate metaphor dying off into a
phrase we all use. You are designing the metaphors and creating the new
language for communication. And each time you come up with something new
and everyone finds it and adopts it-as Tim did, which we instantly adopted
to take to our own purposes- you create this new world.
There was a news broadcaster here in San Francisco years ago, and I'll close
with this thought. At the end of each broadcast, after he told about wars
and disasters and what had gone on during the day, he'd say: "If you
don't like the news, go out and make some of your own." So if you don't
like what we have today in the world of software-- it's hard to like --
then, go out and make some of your own. Thanks very much.
Tim Berners-Lee/JavaOne Page
