[ObWorkRelated: Here are two of Tim's relevant comments on namespaces
(for WISN99?) ]
>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.
>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.
http://java.sun.com:8081/javaone/javaone96/TimBerners-Lee.html
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."