James Gosling presents a discussion of the philosophical and
practical issues that underlie the choices made in the development
of the Java language.
These issues stem from a broad spectrum of areas in computer
science, so the discussion provides a forum for synthesis of what
you have (hopefully) learned so far in your computer science career
and an opportunity to see how these issues come together to influence
real system design decisions. For an upper level computer science
student and for this class in particular the discussion is a good
exercise in its own right.
Java was basically conceived of as a language for enabling
software development that is portable, interpreted, fast, secure,
and an improvement on its benefactor, C++. By addressing these
issues, the designers put into a language many of the issues that
underlie any future of distributed systems & architectures.
The tapes and our discussion of Java, largely comparative in
nature, is not meant to "sell" Java. The hype around it will cover
that fairly well (and James made an apology for that hype in a part
of the tape you did not see--it was not the point of the conference).
Rather the coverage of these important and convincingly argued
issues in our class is meant to demonstrate how language design
occurs and what is behind design decisions so that you can make
informed choices about development platforms. Also it allows us to
look deeper into why the language has become important.
What follows range from full paragraph to brief notes relating
to issues James brought up in the tape. These are in chronological
order from the tape and not logical order of the subject matter.
Portability/mobility of code.
Security checking without cryptography (to avoid the legal bindings
that violate the spirit of open systems).
Focus on performance: deciding what kinds of abstractions are
worth their implementation and performance costs (like true numeric
manipulation rather than bit-restricted). The chosen types in the
language are another example of the influence of performance on
language design (for instance the UNICODE character set was chosen
both for its portability and to make performance better when programs
are designed to deal with more than the ASCII character set)
The lack of global registry for shared packages which James described
wrestling with in the design is a prominent issue (name service) in
distributed systems. By the choice of portability and security the
Java designers were inviting the issues of distributed systems to be
part of their work. The link is circling around to close the circle
now, because Java has paved the way for much more work in code mobility
which shows much promise for advancing the state of the art in distributed
systems.
Default parent of any class is the single class Object, like Smalltalk.
Multiple inheritance was eschewed on essentially a practical basis.
Yes, it is a powerful tool when used correctly, but it is fraught with
difficulties in understanding, implementing, and correctly using its
power. Most of its inappropriate use has been to achieve the concept
of an interface, which was put into the design of Java separately from
the class structure. The primary focus in this choice was in preventing
the increase in design complexity of systems by disallowing a feature
that enables that increase.
Rereleases of classes that are friends with other classes in C++ requires
redistribution and recompilation of the other classes as well. Again,
this patently violates the notion of portability. Phriendly is not a
keyword.
Various gyrations of destructors being called inside constructors
when a failure occurs can force a memory leak (as can a number of other
situations in C++). The security concern of Java made this unacceptable
and it was a major motivator in many design and implementation decisions
to make memory leaks impossible. This is especially relevant in the
context of mobile code, where memory leakage is begging for a viral
invasion.
A summary of the move from C to Java:
C to C++ incorporate some cool new theory that makes
application design and development better
C++ to Java
the cool new theory is well-established and believed
so of course it is supported, but let's incorporate
features that make an appropriate language for developing
distributed systems (portability, security, etc.)
The incorporation of threads came about for all the same reasons (the
stated design goals of the language). The goals made a language-native
implementation of threads a good idea, in part for reasons similar to
why threads are prominent in distributed systems (for example a server
responding to multiple request about the same resource). So, once
again Java ushered into a language paradigm a main issue in distributed
systems.
Java may not be THE distributed systems language (it almost certainly
won't be) but one of its cousins or descendants probably will be. The
philosophies included in Java (for the *first* time in a language) have
set the stage for what must be included in any language that enables
the development of distributed systems.
The syntactical choices made on the basis of meaningfulness to the
programmer improve system reliability (and develepment complexity).
An example: int[] for an int array declaration.
Java is like a means of adding to every system that chooses to
install it an ability to participate in a distributed virtual
machine. It is like your ML VM program raised a level of abstraction.
As we shall see it is implemented underneath "the hood" with the
same abstraction. As suggested in the beginning of this course, the
virtual programming or virtual machine concept is extremely important,
probably now more than ever.
When James spoke about running off the end of an array and banging on
someone else's memory, he neglected to mention that most of the time
the someone else is you.
Dynamic binding of local classes upon arrival by string concatenation
and use of methods in some meta-classes (like his driver loading example)
is another example of a consequence of the Java design choices that
address an important distributed systems issue--mobility and resource
awareness in code.
The use of studies in making design decisions about a language (or
any software development effort) is given little attention in the
literature. It is fortunate that James brought this up on several
occasions, reminding us of its importance as a practical measure for
swaying the decision between countering design choices.
Prior to what you viewed of the second tape, the discussion covered
the following useful packages in the Java environment which you may
want to peruse:
java.lang language utilities
java.util containers, vectors, bitsets, hashing, enumeration, ...
java.io stream io
java.net tcp, sockets
java.awt abstract windowing tool
java.applet for making applets that are embeddable in browsers, etc.