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.