| |
SYS-CON RADIO INTERVIEW
An Interview with...JAMES GOSLING, Creator of Java and Sun Fellow, Sun
Microsystems, Inc.
INTERVIEW BY JASON WESTRA & DAVE JOHNSON at JavaOne 2000
PROFILE IN BRIEF:
James Gosling, the lead engineer and key architect behind the Java
programming language and platform, has been involved in distributed
computing since his arrival at Sun in 1984. His first project was the
NeWSTM window system. Before joining Sun, he built a multiprocessor version
of UNIX, the original Andrew window system and toolkit and several
compilers and mail systems. He also built the original UNIX "Emacs" and
helped build a satellite data acquisition system.
JAVA DEVELOPER'S JOURNAL: James, what do you think about this JavaOne
conference compared to the last five that you've attended?
JAMES GOSLING: I guess I have a hard time believing the exponent and the
growth, it's been something like 35% year over year. I didn't think that
there were this many cool people in the world, having so much fun!
I think the thing that's really dominated the show for me this year
is that there are really people out there doing it, this stuff is out
there, people are really building it. A few years ago, you know, we were
saying "Wouldn't it be cool to do telephones" and last year we were saying
"Hmm, what's happening?" and this year it's like people have got trunkloads
of telephones, trunkloads of pagers.
It's unfortunate being in the United States, where the
infrastructure doesn't really support the cool stuff; maybe we should all
move to Europe or Japan or someplace! But the stuff has been amazing, the
fact that the SmartCard folks have been just going nuts, there's like a
dozen manufacturers of the SmartCard and they're selling like a hundred
million of them this year - all able to run these little cardlets and with
different levels of flexibility and power just do some really entertaining
things.
JDJ: We've actually been interviewing people now for three days straight
and some of the most interesting folks have been in the wireless and the
mobile area. Do you think that's definitely been the theme for this Java
conference?
JG: It's certainly been our theme. I guess that one of the problems at
these conferences is that there's no such thing as THE theme, because
there's just so much going on. Certainly all the enterprise stuff is a big
thing, but the wireless stuff has been just going nuts, I mean there's all
these people doing Java code inside the end point - for example there were
those demos this morning that the folks from Motorola did, and there all
these guys from companies like Samsung. It's just going nuts. But one of
the things about the wireless world is that there's usually the other side
of it, right? You can talk from wireless thing to another, but often the
most interesting thing is when the wireless gizmo is talking into the
infrastructure. So even for what people think of as the "dumb" smart phones
like the WAP phones and that, a lot of the infrastructure pieces of the WAP
world is people using JavaServer Pages. JaveServer Pages, you know, they're
not just for HTML any more. People have been doing XML and WML, all kinds
of stuff, straight out of JavaServer Pages.
JDJ: Where are you focusing your efforts right now, what are you working on
or what's the team around you working on at Sun?
JG: What am I actually working on? Well, the project I am desperately
trying to finish right now is this sort of document management thing for
Sun Labs. I made the mistake a few months ago of saying, "So where do I
find a copy of this?" and we have this ten-year old filing system that's
like bits of paper and there's an online file you grab and it's completely
useless, so I've been dealing with all this stuff with JavaServer pages, so
you can actually find the freakin' tech reports and know where they are!
Most of these tech reports are online somewhere, but who knows where? So
that's what I've been spending the last month or so of hacking time doing.
But actually I've been starting a project and doing stuff for developer
tools. One of the things I've been interested in lately is, if you go
around and look at the desks of most of the top-line developers, do you see
them using any of these fancy IDEs? No. Mostly it's like Emacs, VR, Shell
script..and it just goes, right? And you ask them why and it's like, "Well,
I did an IDE once and found that the layout was too simple when I actually
wanted to write a program." Most of these IDEs actually try to prevent you
from writing a program, they try to make it easy for people who don't know
how to write programs, and near as I can tell no one is building tools for
people who actually write programs and I'm sorry, making my keywords bold
face and red doesn't count. Having a certain responsibility for Emacs, and
Emacs is this thing that's like 25 years old, I find it kind of amazing
that 25 years later the state of the art for folks like me hasn't gotten
any better. So now I'm spending time building stuff for me, not for anybody
else. I figure that if I can build a tool that I find actually useful, then
I'll count myself lucky...
JDJ: ...and the rest of the generation will probably use it as well.
JG: Well maybe. I mean one of things that got me thinking about this is
that I did a tool about 10 years ago. We had this little crisis in the
graphics world, where we had to write a whole new set of graphics libraries
for an odd sort of reason. I don't know how many of view have actually
written graphics algorithms, but you pull open your average graphics
textbook and they have a bunch of standard algorithms and probably the
first one that you see is Bresenham's [line drawing] algorithm. It's really
simple, you write it and it's like five lines of code, real easy and
straightforward and you can look at it and understand why it works and it
looks like it's correct. But then you go to work for somebody that actually
does graphics and you find out, where is the drawing routine? It's not five
lines, it's not even 5,000 lines: it's like 50,000 lines, and it's doing
this special case, that special case, horizontal lines, vertical
lines...alphablending, trying to deal with 1-bit frame buffers, 8-bit frame
buffers, 15-bit, 16-bit, 32-bit...all of these different bit depths and
this interleaves to all these issues like crash lines, and you find that
you've got like a gazillion different line drawing routines and you have to
figure out which one to call. And a lot of the ccomplexity is figuring out
which are the optimized ones. And yet, at the core they're all Bresenham's
algorithm, and so I built this tool that was sort of a combination
macro-preprocessor and theorem prover, one where you could define rules to
do tree replacements. Where you could say if you see this then replace it
with that - it was based on the semantic graph, not on text strings, and if
you were clever about the way the rules were built, you could actually turn
it into a theorem prover. And it had basic primitives, like my favorite one
was one called trade-off. Tradeoff of A,B takes two code fragments presumed
to compute the same thing, and it did a space estimate and a time estimate
for each of them. All the code was annotated with branch probabilities and
they would pick the one that was most appropriate right there. The whole
goal was to be able to write the algorithm really simply and then write
what were transformations on algorithms. And so if you believe the
transformations and you believe the algorithm then you could believe that
the end result was correct. Because a lot of the problem in writing these
things is that you've got 1,000 clones of exactly the same piece of code,
kind of the same but doing it slightly differently. So this particular tool
was trying to deal with that, and I thought it was really successful work
really. But the problem was that I managed to explain it to no more than
about five people! It was a little bit too weird.
JDJ: Well you've managed to explain it to a heck of a lot more than five
people now. Are you going to be releasing this for open source? Or, if not,
what's your view on open source right now?
JG: Well I don't know that I'd really want to release THAT one, somebody
did ask me for the source code a while ago and I actually did manage to
find a version that would compile and run but documentation was not real
obvious and it's not exactly an obvious thing but I'm trying to build a new
one. What do I think about open source? I basically like open source a lot,
I mean the Java source code has been out there from the very beginning,
it's good for a lot of things. One of the unfortunate things in the open
source movement though is that they get into these really weird religious
wars about, you know, "You're not open source... I am." "No, no, he's not
open source..." - there's like half a dozen different open source licenses
that call themselves the one true open source and my view is like, get over
it guys. We [at Sun] get criticized because our open souirce license
doesn't work exactly like the [BSE] open source license, or the Mazillo
open source license or whichever, take your pick. But ours doesn't look
like those because there's something that we actually care about and the
thing that we care about is that if somebody says "This is a Java runtime"
then people who plug programs into that, we think, have a right to know
that they're going to run. In a community of people who are all sort of
well-meaning and it's all sort of peace, love and happiness, you don't
really need licenses because you can trust everybody; but in a world where
there exist untrustworthy people - and certainly you have the example of
one really SERIOUSLY untrustworthy...and we ended up in court about
it...[they were trying] to turn it into something that was incompatible
with everything else and really frightening the community and it was and
continues to be really important for us to make sure that, if somebody
calls something a Java compiler or a Java runtime, that it actually runs
Java programs from other people's compilers and that run on other people's
runtimes, and our license merely says that we care about that. Beyond that,
we're pretty close to being as free and open as you can be.
JDJ: I think the Java Community Process is testament to that. Have you had
a chance to see any of the devices here, I'm talking about wireless and so
on, there's a little PDA for example that's got a built-in wireless
connection, have you see any cool gadgets like that?
JG: Well, this place is like wall-to-wall cool gadgets! I don't know which
is my favorite, but the one that turned my head sideways the most is this
little cell phone that Samsung in Korea have, a tiny little thing in
between the size of a postage stamp and a credit card, there was an
Internet browser and it ran Javacode and all the other usual stuff besides
being really teeny. But it was done in this opalescent mother-of-pearl
thing, it was clearly designed to be like a piece of women's jewellery, it
was really strange.
JDJ: What type of things would you like to see in Java Developer's Journal?
We definitely support the education of our readers and, with your vision,
what type of things would like to see us including in the journal?
JG: You guys already do a lot of what I think is the really important
thing, namely going through tutorials if you want to call them that, some
of the things that I've seen in JDJ are in the space between tutorials and
case studies, you know, like "This is how you do this, or this is how I did
that" and when I look at it that's often the most valuable thing, for me.
JDJ: Some of the topics we cover are Enterprise JavaBeans, Servlets as well
as GUI widgets, we have deciated columns etc. Are there any other facets of
Java, since it's such a broad topic, that you'd like to see covered on a
monthly basis. I understand that your working for instance on the realtime
spec - is that something that's important enough for us to get it in there,
is there enough support in the industry right now for us to start educating
readers on it?
JG: Well I've certainly been involved in the realtime stuff. The realtime
community tends to be relatively small and pretty fanatical, I don't know
what percentage of your readers are realtime types...[but] I would be
tickled if there were actually realtime articles in there. Actually if
there were enough RealTime Java programmers to justify a regular
column...that would actually make me really nervous. I mean think about it,
it's like enough people writing flight control systems for airplanes and
factory floors and whatever to actually [get the attention of] a large
mainline magazine for programming that stuff...that would be a little odd.
One of the things I noticed that was a little odd was that we did this
thing on Monday night, a sort of extended Q&A session, and at one point one
of the people on stage asked the people in the audience, "Stand up if
you're writing server software", then "Stand up if you're writing embedded
cell phone software" and a few people rose; then "Stand up if you're
writing software for smart cards", and like one person stood up. And it was
interesting that there was this sort of inverse relationship between volume
and the number of developers working there. I mean the volume of smart
cards just dwarfs everything else, and the number of people actually
developing smart card stuff is pretty small. Embedded stuff is a lot
bigger, but it's not nearly the kind of diversity of stuff that's going on
in the infrastructure that all these pieces are talking to.
JDJ: Could you just give a real layman's explanation of what the realtime
specification for Java is going to be utilized for? For example you can
write a hardware driver with it, I believe, is that correct?
JG: Yes, you could write hardware drivers with it - actually people have
written hardware drivers with Java straight before, you know it's not too
hard to get there. What's really at the core of any system that calls
itself realtime is that you're dealing with deterministic timing, so there
are sets of classes for dealing with timing of events that recur, there's
all sorts of weird scheduling stuff, and these things sort of interrelate.
In a typical computer system schedulers are oriented towards maximizing
thruput, and maximizing thruput and maximizing determinism are often at
cross-purposes and so one of the things in the scheduling in realtime
systems is this notion of feasibility analysis, where you've got a set of
threads and you're asking the question, can you actually meet the demands
of all of these threads; and the threads get to say, "I need this" and one
of the answers from the feasibility analysis is "No" - at which point you
either..you know, it's like you press the On button on the airplane, and
the system goes through a feasibility analysis and it says "Did he install
a big enough CPU? No? [Then] I'm not going to start the engine." Whereas in
most systems you just try as hard as you can. Another piece of the
determinism has to do with the garbage collection: there's a mechanism in
there for running threads concurrently with the garbage collector, and that
turns out to be just plain ugly. One of the things that there was a certain
amount of hope for early on was that the state of the art in realtime
garbage collection would be good enough that we could just say, you know,
"Use a realtime garbage collector." But after studying bunches of PhD
theses on realtime garbage collection, they were like close but no cigar. I
mean a lot of them had problems like "Well, it's realtime mostly but every
now and again we just have to stop." And that...if you have to stop once
every three or four hours, your airplane isn't going to make it from San
Francisco to New York! The other common problem is that they would say
"We're realtime, we can do [GCs] in under 3-4 milliseconds" and for some
people that actually works - [but] one of the problems in the realtime
world is that it means different things to different people. So for some
people realtime means getting it done within the second; for others,
realtime means well under a millisecond. The demo that was done this
morning, [by] the guys from Agile - the specialized Java chip - their
definition of realtime responsiveness, which really shows up in their
thread-to-thread context switch time, is like 500 nanoseconds. They can do
a thread switch faster than some systems can add!
JDJ: Thanks very much, thanks for letting us know about the realtime
systems. We have to wrap up and let you get on to your next appointment, so
can you finally just tell us what you think about the JavaOne 2000
conference, and what you look forward to seeing at the next JavaOne, next
year?
JG: The whole thing about JavaOne for me is just the amount of really cool
people. People ask me, "Don't you get upset with people coming up and
asking you really stupid questions?" and the answer is no - actually,
almost nobody asks me stupid questions, they usually ask me really good
questions, questions that have me going "I don't know the answer to that" -
and I find that really cool. And just the sort of connections that get
made, you know, I don't know how many of these funny contacts that have
goine on are going to turn into anything - these contests are not "Throw a
nickel into the cup and get a dollar" they are "Write a Java application in
six hours and start a new company". I don't know if the fellow who won the
Motorola contest is going to do with his baseball application, but that's
pretty amazing, I don't think anywhere else would you see people attending
who could participate in contests where that kind of stuff went on. It's
just wonderful.
JDJ: Have you been to any of the many parties going on after JavaOne is
complete each day here?
JG: Well, my day at JavaOne starts at about six a.m. - so I've been to a
couple of things but typically by about 8 p.m. all I can do is just...I'm
just flat and I end up doing things...unfortunately for me this is a job,
and I end up having to go and do things. I haven't had a chance to go to as
many parties as I would like to but they've generally been pretty good.
JDJ: Well thanks a lot. Ladies and gentlemen, this has been James Gosling.
We appreciate your time.
|
|
