Internet Insight: Brewing Conflict

James Gosling, a Sun fellow, is the lead engineer and architect of the Java programming language and platform. Gosling has been involved in distributed computing since his arrival at Sun Microsystems Inc. in 1984. One of his major recent projects has been the Real Time Specification for Java, which became final in November (www.rtj.org). Before joining Sun, in Palo Alto, Calif., he built a multiprocessor version of Unix, the original Andrew window system and tool kit, and several compilers and mail systems. He earned his bachelors degree at the University of Calgary and his doctorate at Carnegie Mellon University. He was interviewed by eWeek Technology Editor Peter Coffee.

eWeek: We asked our readers in an online poll which platform they expect to dominate in Web services: With more than 1,600 responses, the split is almost exactly fifty-fifty between Visual Studio .Net and J2EE (Java 2 Enterprise Edition). First, is that even the right comparison to make? Second, whats your outlook?

Gosling: Its kind of odd that .Net is getting anywhere near half the votes, since J2EE is all over the place. Its what people are using. Ill try to rise above snide remarks, but—just for example—the security section of the [Simple Object Access Protocol] specification is, literally, empty. Comparing J2EE and .Net isnt easy. The J2EE umbrella is a collection of different technologies. The larger, more adventurous systems need all of it; lots of folks get by just using [JavaServer Pages] and rolling an in-memory database. People use whats appropriate to the problem at hand.

I cant, in all honesty, speak with authority about .Net, but I certainly dont see the situation as an either/or choice between .Net and J2EE. A central principle of the Java world is modularity, plug-in/plug-out: All the APIs actually do work together. I will point out that the J2EE market is a community, while .Net is the product of a corporation.

eWeek: Thats one of the questions often raised—the degree to which the Java platform is, or isnt, controlled in every way that matters by Sun. How do you respond to that?

Gosling: Sun is involved in many different APIs, but we have input from many groups—from all walks of life, with many different experiences.

eWeek: Do you expect continued API growth? And, if so, where?

Gosling: The new APIs are the core of Javas growth. One of the most interesting things is that its hard to segment whats most or least interesting. There are people doing APIs for controlling giant telescopes; theyre very interested in that, but theyre 0.0001 percent of the population.

You cant draw sharp boundaries: Java 2 Micro Edition on a handheld device often ties in to a [J2EE] back end. Theyre all interconnected.

The mobile devices are certainly an area of growth. At JavaOne last year, the thing that was most exciting was that J2ME cell phones were starting to get traction. Now that theyve had a year of development, things are really going.

eWeek: Are you using one?

Gosling: I wish. In North America, the infrastructure sucks. In terms of wireless, always-on Internet access, were in third place to the Far East and Europe. When you go overseas and see [third-generation] phones with decent digital connectivity, being in North America is really frustrating.

eWeek: When you look at whats been accomplished with Java since its introduction, what do you consider its biggest achievements?

Gosling: Its certainly worked well for heterogeneity. There are all kinds of processes running in Java, on all kinds of machines. The security story has been good. Reliability, developer productivity and scalability; when we say "from smart cards to supercomputers," it isnt just a slogan.

eWeek: Of those, which do you think is the least appreciated?

Gosling: Developer productivity. Developers know that theres roughly a factor of 2, but no ones marketing really talks about it.

eWeek: Why so little notice? Arent development costs the only IT cost that rises over time?

Gosling: It beats the heck out of me. There are things IT managers care about more, like dealing with heterogeneity. Its odd. Dentists, doctors and carpenters expect to invest in tools, but developers dont get that kind of investment. The tool companies have been in this price death spiral; theres this expectation in the market that tools are free, or near free, and that makes it hard for a business. Programmers spend more on lattes than on tools.

eWeek: Some .Net proponents say the Java platform is too confined to the Java language. Your response?

Gosling: The Java Virtual Machine supports many different languages. Most of the commercial Ada compilers target JVM, and many defense projects use that. We support all kinds of languages—but we dont say that were willing to support all languages. That [selective support] has to do with issues of what you can prove, from a security point of view. There are good reasons not to try to support C and C++. Supporting them drives you to support unrestricted pointer operations. The security story goes out the window; the reliability story is trashed as well, and that backs you into the security problem from another direction.

eWeek: Whats your view of the state of application security?

Gosling: There are two kinds of security problems. The first kind arises where people are too stupid for words. Outlook is a petri dish. I dont know why anyone uses it.

The rest are primarily bugs, often memory integrity bugs; many of those are array overruns. Java doesnt have those. You were talking about unappreciated features: Theres the verifier in JVM. It does some limited theorem proving to show that a program has certain properties.

It establishes that interfaces have integrity. When you know what the interfaces are, the internals of objects can change without breaking things—which is essential, nothing gets designed and then cast in concrete.

eWeek: As to warped reality, are there any perceptions of Java that you find especially hard to dislodge?

Gosling: The worst myth is "Java is slow." The just-in-time compilers today are very good. My benchmarks beat C and C++ code. We know the exact chip set youre running on, so we can optimize for that exact chip instead of making generic optimizations. The static compilers dont know what your program will actually do; our compilers can do extra-aggressive optimizations, where they do the most good. That would give you incredible code bloat if you did them all over the place.

The other complaint is that the Java Community Process is slow. Ive evolved a standard reply: Democracies do work more slowly than dictatorships, but over the centuries, societies have decided that the price is well paid.