X

A closer look at Java

James Gosling gets down to the nitty-gritty on Sun's software and assesses the open-source odds.

Stephen Shankland Former Principal Writer
Stephen Shankland worked at CNET from 1998 to 2024 and wrote about processors, digital photography, AI, quantum computing, computer science, materials science, supercomputers, drones, browsers, 3D printing, USB, and new computing technology in general. He has a soft spot in his heart for standards groups and I/O interfaces. His first big scoop was about radioactive cat poop.
Expertise Processors, semiconductors, web browsers, quantum computing, supercomputers, AI, 3D printing, drones, computer science, physics, programming, materials science, USB, UWB, Android, digital photography, science. Credentials
  • Shankland covered the tech industry for more than 25 years and was a science writer for five years before that. He has deep expertise in microprocessors, digital photography, computer hardware and software, internet standards, web technology, and more.
Stephen Shankland
9 min read
SAN FRANCISCO--Ten years ago, Sun Microsystems publicly debuted Java, software that initially helped establish the company's forward-thinking reputation and that later spread to most corners of the computer industry. James Gosling is the man behind the technology.

In the early 1990s, Gosling initiated and led a project code-named Green that eventually became Java. The basic idea behind it is that a program will run on a variety of computing devices without having to be customized for each one. For example, a game written for a one cell phone equipped with what's called a Java virtual machine should work on another.

The technology has faced numerous challenges over the last decade. Early ally Microsoft, realizing that the universality of Java programs didn't bode well for Windows, created a Windows-specific version of Java that worked slightly differently and triggered a seven-year legal fight. Different flavors of Java had to be created for domains such as gadgets, PCs and servers. Sun struggled to find a good way to share control over Java with other companies. And now many, including IBM, are calling on Sun to release the core parts of Java as open-source software.

Despite it all, Java has become a fixture in the computing realm. Sun Chief Executive Scott McNealy can be prone to grandiose statements, but he wasn't far off the mark when he declared on Tuesday at Sun's JavaOne trade show, "It would almost be embarrassing to listen to the JavaOne keynotes from seven, eight or nine years ago. We absolutely underhyped it. We had no clue what this technology was going to do."

Gosling is on constant display at JavaOne trade show this week, now sporting a mane of white hair and an invariable outfit of jeans, T-shirt and Birkenstock shoes. "He looks like an aging hippie," his daughter said in a tribute video Tuesday that had the 50-year-old Java patriarch blushing on stage.

CNET News.com's Stephen Shankland sat down on Tuesday to hear Gosling's thoughts on Java.

Q: When you started designing Java, did you have in mind a concept of what it might become?
Gosling: Back in the Green project days, we talked a lot about the long-distance future. We wrote up a little book of scenarios. A lot of the design of Java was driven by that scenario exercise that we went through. For me, it was more an exercise in science fiction. You never really know which way the world is going to go. You get moderately good at reading the way the wind is blowing and forecasting technology, but there's a long distance between speculating and believing it would happen. I certainly believed that Moore's Law was on a rail, and it was pretty easy to connect the dots as networking spread.

Working together means you have to like working together. For Microsoft, that's been a long educational process. They don't seem to like it.

I was absolutely confident that the various technologies were going to go that way and there were issues that were going to happen around security and reliability and portability. Ending up actually participating in the big part of answering those questions is really what came as surprise.

You started Green as just a project for consumer electronics, though?
Gosling: When we originally started thinking about it, we spent a lot of time talking to people in all kinds or areas. We saw similar things happening in consumer electronics and the emerging cell phone world and embedded control systems. We talked to people who made elevators, locomotives, lighting control systems and stuff in automobiles. We also talked to (developers of) VCRs and televisions. In the first round, the Green project, we decided we wanted to do a prototype. We had to focus. Largely because it was more entertaining, we picked consumer electronics.

Lots of people thought it was interesting, but then we asked, is there some way we can turn this into something that can support itself? At about that time, Time Warner came out with their full-services network RFP (request for proposals). It was pretty much our fantasy--networking to the home, voice over network, video over network, interactive content. It was, "Yes! This is what we want, what we're working towards." We jumped in.

This was essentially the early days of interactive TV?
Gosling: Yeah. It was a pretty visionary proposal. There were a lot of people who said, "We gotta be that too."

The thing with Time Warner got really strange for a wide variety of reasons, and we ended up losing that bid. In retrospect, I'm glad we ended up losing (to Silicon Graphics). SGI went and spent unbelievable amounts of money trying to do this and got no money to help support it.

Did you conceive of Java as something for this narrow domain or as something that might splash all over the computing industry?
Gosling: It wasn't so much that we planned to splash across the industry. What happened was we looked at all these industries and they were doing similar things at some gut level. Everyone was building systems that had digital controllers in them. But there are huge interoperability problems. It was a matter of observation to notice that all these things were going to get unified. You're standing outside a demolition derby and you notice all the cars are pointed toward the center of the arena and they're going to smack.

So Java solved some interoperability problems. But Microsoft went its own way with .Net, which essentially created a higher-level interoperability problem. Is there a way to merge .Net and Java into one technology?
Gosling: In some sense that's what Web services are. They're a bridge. But you can't weld things together when they don't want to be welded together. Microsoft has explicit policies of being different. They like to be different. They were actually very upstanding, lovely members of the Java community for six months or a year, then they decided that was a bad idea.

In C, you have to be able to lie about the identity of things, and in Java, you're absolutely forbidden from lying about the identity of things.

Was that 1995 or 1996?
Gosling: That would be 1996, I guess. But working together means you have to like working together. For Microsoft, that's been a long educational process. They don't seem to like it. They seem to be getting closer. We do an awful lot to work with them, but it's a little at more arm's length. We do (interfaces) in common, Web services, interoperability.

Could you feed programs written for .Net in the C# language into a Java virtual machine?
Gosling: The only serious divide is they have this unsafe mode which they use a lot. One of the principles I believe

in is there shouldn't be an unsafe mode.

What do you mean by unsafe?
Gosling: They have a notion of managed code and unmanaged code. Managed code is the kind you can make security and reliability statements about. (But with unmanaged code), you can't depend on anything anymore. Memory corruption is indistinguishable from correct behavior. It's pretty difficult to analyze what a program is doing. C programs (a type of unmanaged code) tend to fail in mysterious ways. It ends up having deep implications about how security mechanisms work. In C, you have to be able to lie about the identity of things, and in Java, you're absolutely forbidden from lying about the identity of things.

What would it take to get Microsoft to join the Java Community Process (JCP)?
Gosling: I don't have a clue. Ask (Sun Chief Technology Officer) Greg Papadopoulos.

Would you like to see things back like they were in that six-month honeymoon period?
Gosling: I would love to see them collaborate with the rest of the community of the JCP.

The big difference in the last five years vs. the first five years is that Java has become a central part of many gigantic, mission-critical systems.

You just released Sun's Java application server as open-source software through the GlassFish project. Are there lessons you hope to learn there that might apply to the possibility of releasing Java Standard Edition (the foundation of Java) as open-source software?
Gosling: Maybe. Just about everything we do about the way Java SE is run is very much like an open-source project. The major dividing line is our license has this testing requirement. When we've done surveys of places that use Java really heavily, the whole testing thing turns out to be a really big issue. There's all the folks in the open-source community who on the one hand say, yes, we're going to test, we just don't want to agree to test. It's conceivable we could some day (release Java SE as open-source software). A lot depends on how comfortable the community gets.

There are a lot of negative examples that make us really nervous. If you look at people's experience with JavaScript (a language for advanced Web pages that's not related to Java). There are interoperability issues there between all the different flavors of JavaScript that are nightmarish for people doing Web page authoring. If you want to make it run on this browser, make it this way. If you want to make it run on that browser, do it that way. People in the Java world look at the JavaScript manuals and go, that's a horrible thing.

But with Java, companies like BEA Systems would add special features that would be available only if you ran the software on their Java application servers. So Java code wasn't so portable after all.
Gosling: Yes, that's a problem. But at least the way it's always been done is that at least these special features are special features. There's a facility in Java about package naming. When you use an API (application programming interface), you have to explicitly use what's a public standard API--java.something-or-other--or are you using one of the corporate proprietary ones--com.bea.something-or-other. It forces you as a developer to be explicitly aware. The developers really cared about portability. Every time they have to write com.bea, they feel the claws biting into their skins. One thing difficult in the JavaScript world is that you can't really tell that you're using a feature specific to this browser or that browser.

Also, the way things have tended to evolve is you get one application server vendor who will come up with some idea, there will be general acknowledgement that it was a good idea, and often that would turn into a JSR (Java specification request). The company's second or third version of that would be within the standard Java framework.

Can't you release Java as open-source software and control compatibility through branding? You could require software to be certified before it's allowed to use the Java name.

Gosling: There's been a lot of discussion about that. Sun is a democracy, and some believe it could work and some people don't. Right now there are more nays than yeas.

Are you in the nay category?
Gosling: More often than not I'm in the yea category. But I have to admit I go back and forth.

Compare working on Java five years ago to today.
Gosling: The big difference in the last five years vs. the first five years is that Java has become a central part of many gigantic, mission-critical systems. That requires a paranoid conservatism. When you've got large banks clearing hundreds of billions of financial transaction every night, small bugs have big consequences. Early on, we could do all kinds of crazy stuff, but now we have to worry hard about who we actually affect. Every bug we fix causes problems for somebody who had done a weird workaround. It becomes a very meticulous discipline.

Through projects such as Groovy, Sun is talking about moving the worlds of Java and scripting languages closer together. But I confess I'm not sure how exactly programming languages are different from scripting languages such as PHP, Perl or Python.
Gosling: Your confusion is well founded. There's an awful lot of loose language. The terms tend to mean different things to different people.

When people talk about scripting languages, they often talk about things that are more toward having a developer be able to slap something together really quickly and get a demo out the door in minutes. How fast the thing runs or how well the thing scales or how large a system you can build tend to be secondary considerations. In the design of Java, we didn't care so much about how quickly you could get the demo out the door, we cared about how quickly we could get a large, scalable system out the door. We ended up making difficult decisions. In general, scripting languages are a lot easier to design than the real programming languages.

The Java design is at two levels: the Java virtual machine and the Java language. All the hard stuff is at the JVM and below. If you can build a scripting language that targets the JVM, you get a certain amount of both properties.

So you're executing script in a JVM?
Gosling: Yeah. All the Java libraries are available to things written in Groovy. And Java applications can use Groovy. They can incorporate Groovy scriptlets.