|
March 28, 2002 --
It happens a few times in life -- the chance to ask a question of an
exceptional person who has contributed to the evolution of technology,
and as a result, has significantly influenced many people. Members of
the Java Developer Connection
[(JDC) program] recently took this opportunity when the JDC
posted a poll, "Ask James Gosling."
James Gosling, vice president and fellow at Sun Microsystems, also known
as the "father" of the Java
programming language, created the original design of the language and
implemented its original compiler and virtual machine. He is a recent
contributor to the Real-time Specification for the Java platform, and is
currently a researcher at Sun labs, where his primary interest is
software development tools.
Gosling sat down with the JDC and answered some of the many questions
received as a result of the poll. Read Gosling's insight into the future
of Java technology and more.
JAVA DEVELOPER CONNECTION PROGRAM (JDC): If you could start
again, would you make everything an object rather than the current int,
boolean, byte, etc, viz-a-viz object disconnect?
JAMES GOSLING: No, actually I tend to go the other way, which is
to say, a way to make classes behave more like primitives, so that they
can be optimized and become extremely efficient, and maybe have a way to
do autoboxing so that they sort of go back and forth between being
objects. There are a lot of subtle problems around autoboxing that
always make me nervous, and the big one being questions around identity.
JDC: The Java language adds features with every release, and
this is generally good, but the whole thing is getting pretty large. If
you could take a few things out, what would they be?
JG: The Java language actually doesn't add very many features.
The Java language itself has been very, very stable, and relatively few
things have actually been added in any release. What has really gone
nuts is all the different APIs that are part of [the Java 2
Platform, Standard Edition,] J2SETM. And this question, in some sense, is
unanswerable. It says, if you could take a few things out of
[the] J2SE [platform], what would they be? One of the
tragedies we have is that we've got so many customers and everything
that is in the platform is critical to a pretty large group of
customers. So, for any particular person, any particular developer, not
all of [the] J2SE [platform] is going to matter. But
for every developer, the slice of the platform that they care about is
different. It's always a constant struggle to try to avoid putting
things in. And actually, if I had to pick some API that I've never used
- honest I've never used the [Java DataBase Connectivity
] JDBC
APIs. I've never written a piece of code that used the database stuff.
So, personally, you could delete [the] JDBC [API] from
[the] J2SE [platform] and it would not affect any code
that I've ever written. But lots of other people would be really upset.
JDC: Where do you see Java technology in the next five
years?
JG: I think the most interesting trend that's going on right now
is the sort of really pervasive use of Java technology in all kinds of
interesting places that are on the edges of the network. A lot of the
infrastructure stuff that is in the enterprise has gotten really well
established, but there is a lot of upcoming stuff in the way that people
use Java technology in sort of embedded systems; things like cell
phones, automobiles, realtime systems that are getting pretty
interesting and giving people this ability to build systems in an
end-to-end way that I think is getting very compelling.
JDC: About realtime: This developer is building some kind of
ship simulation...I am writing a ship maneuvering simulator. It should
simulate the trajectory of a ship and present its view to the user in
approximately real time. Do I need to use the reference implementation
of the realtime spec?
JG: I would say not. If you are doing simulation at all, that's
not what the realtime spec is about. The realtime spec is about doing
things predictably with very exact timing. And so, the hard part of
this question is not the actual simulation part -- because that's not
really relative to realtime -- but the display of the trajectory of the
ship on the screen. And boy, every ship I've ever seen moves pretty
slowly.
The stuff that's in the Java [platform] realtime specification
is really only important if your timing constraints are very tight: if
you are down in the sort of regime where you can't tolerate delays of
more than a millisecond or so. With most things that people do in the
Java programming language, you can just do regular Java
[technology] code on a regular Java VM, and you'll be pretty
close to realtime. Certainly within seconds and almost always within
tenths to hundredths of seconds, you will be accurate. Things around
garbage collection can become difficult, but with the incremental
garbage collector in a hot spot it's rarely an actual issue.
JDC: I'd like to see more tools that enhance developer
productivity, we have Unified Modeling Language (UML) modeling tools,
and wizards to help us generate code. Can we tie these together
better?
JG: In some sense that kind of thing has been the goal of the
NetBeans [software] Project
from the beginning. The really interesting thing about NetBeans
[software] is that it has an API for things like UML modeling
tools and cogeneration wizards to fit together in the same platform.
People have done a fair amount of this in the past and been quite
successful.
JDC: What do you think is the most important area for students
to study in order to be successful in the computer industry? Not just
the Java technologies, but what other disciplines?
JG: Certainly there are a lot of various things that are
generally called software engineering that you can find in all kinds of
books, like the refactoring books, and some of the pattern books are
very good. Personally, I think one of the areas that's really important
to understand is algorithms and the analysis of algorithms. There's a
lot that [subject] gives you in terms of insight about how
things behave.
JDC: Why is Throwable not an interface? The name kind of
suggests it should have been. Being able to catch for types, that is,
something like try{}catch (<some interface or class>),
instead of only classes. That would make [the] Java
[programming language] much more flexible.
JG: The reason that the Throwable and the rest of those guys are
not interfaces is because we decided, or I decided fairly early on. I
decided that I wanted to have some state associated with every exception
that gets thrown. And you can't do that with interfaces; you can only
do that with classes. The state that's there is basically standard.
There's a message, there's a snapshot, stuff like that — that's
always there. and also, if you make Throwable an interface the
temptation is to assign, to make any old object be a Throwable thing.
It feels stylistically that throwing general objects is probably a bad
idea, that the things you want to throw really ought to be things that
are intended to be exceptions that really capture the nature of the
exception and what went on. They're not just general data structures.
| 
Print-friendly Version
