|
Unix Programming - Language Evaluations - Java
The Java programming language was designed to be “write
once, run anywhere” and to support embedding interactive
programs (or applets) in Web pages that would
be runnable from any browser. Thanks to a series of technical and
strategic blunders by its owner, Sun
Microsystems, it has failed in both its original
objectives. But it is still sufficiently strong at both systems and
applications programming to be seriously challenging
C and C++. Java was announced in 1995.
Java is cleverly designed to capture the huge benefit of
automatic memory management and the lesser but not insignificant
benefit of supporting OO design, while being far smaller and
simpler than C++. It retains a broadly C-like syntax
that most programmers will find comfortable. It includes support for
callouts to dynamically-loaded C and calling Java as an embedded
language from C. Nor is it trivial that Sun has done an excellent job of making
good Java documentation available on the Web.
Against Java, we can say that (compared to, say,
Python) some
parts of it appear over-complex and others deficient. Java's
class-visibility and implicit-scoping rules are baroque. The interface
facility avoids complex problems with multiple inheritance at the cost
of being only slightly less difficult to understand and use in itself.
Features like inner and anonymous classes can lead to very confusing
code. The absence of reliable destructor methods means that it is
difficult to ensure proper management of resources other than memory,
such as mutexes and file locks. Significant parts of the Unix
operating-system facilities are not accessible from stock Java,
including signals, poll, and select. While Java's I/O facilities are
very powerful, simple reading of text files is not simple.
There is a particularly invidious problem, resembling Windows
DLL hell, with libraries. Java has no method to manage
different library versions. This can create huge problems in
environments like application servers, where the server might come
equipped with one version of (say) an XML library, but the application
ships with a different (usually newer) version. The only handle on
such problems is the CLASSPATH environment variable,
a source of chronic deployment problems.
Furthermore, Sun's handling of the Java language has been both
politically and technically obtuse. Java's first GUI toolkit, AWT, was
a mess that had to be essentially replaced. Withdrawing the language
from ECMA/ISO standardization further nettled many developers already
upset by features of the Sun Community Source License (SCSL).
Restrictions in the SCSL continue to hamper open-source
implementations of Java 1.2 and their J2EE (Java 2 Enterprise Edition)
specification. This compromises Java's original objective of
universal portability.
Sadly, browser applets are dead.
Microsoft's
decision not to support Java 1.2 in Internet Explorer effectively
killed them. However, Java seems to have found a secure niche in the
computing ecology, for ‘servlets’ running within Web
application servers. It has also become commonly used for a lot of
in-house corporate programming not directly tied to databases or
webservers. It has become major competition for both Microsoft's
ASP/COM platform and Perl CGIs. Finally, it is in widespread and
increasing use as a language for teaching introductory programming (a
role for which it is extremely well suited).
Overall, we can fairly judge Java to be superior to
C++ (which is
both far more complex and does less to attack the memory-management
problem) for all but systems programming and the most speed-critical
applications. Experience seems to show that Java programmers are
somewhat less likely to fall into the trap of excessive
OO
layering than are C++ programmers, though this remains a significant
problem.
How Java will fare in equilibrium with the other languages
we describe here is unclear as yet, and may depend largely on project
scale. We may expect its proper niche to resemble
Python's. Like Python, it cannot compete with
C or
C++ on raw
execution speed, nor against Perl on small projects that use
pattern-driven editing heavily. It is (more definitely than Python)
overkill for small projects. We may guess that Python will have an
edge in smaller projects and Java in larger ones, but the verdict of
experience is not yet in.
The best single reference on paper is probably Java
In A Nutshell [FlanaganJava], but this is
not the best tutorial introduction; that would probably be
Thinking in Java [Eckel]. Trails to all the world's Java websites begin at
Sun's Java site, which also
has complete HTML documentation available for download for free. The
Open
Directory Java Page also collects useful Java links.
Java implementations are available for all Unixes, for
Microsoft operating systems, MacOS, and many other platforms.
Sources for Kaffe, an open-source Java implementation with class
libraries conforming to most of JDK 1.1 and portions of JDK 1.2,
are available at the Kaffe project site.
There is a Java front end for GCC. GCJ can compile Java code to
either Java bytecode or native code, and can compile Java bytecode to
native code as well. It comes packaged with open-source class
libraries that implement most of JDK 1.2, and a Java bytecode
interpreter called gij. Details are at the
GCJ project page.
There is a Java IDE for Emacs at the JDEE project site.
Java portability is excellent at the language level. Incomplete
library implementations (especially older JDK 1.1 versions that don't
support the newer JDK 1.2) can be an issue.
Java's best side is that it comes close enough to
achieving write-once-run-anywhere to be useful as an OS-independent
environment of its own. Its worst side is that the Java 1/Java 2
split compromises that goal in deeply frustrating ways.
Freenet is a peer-to-peer networking project that is intended to
make censorship and content suppression
impossible.[127] Freenet developers envision the
following applications:
-
Uncensorable dissemination of controversial information: Freenet
protects freedom of speech by enabling anonymous and uncensorable
publication of material ranging from grassroots alternative journalism
to banned exposs.
-
Efficient distribution of high-bandwidth content: Freenet's
adaptive caching and mirroring is being used to distribute Debian
Linux software updates.
-
Universal personal publishing: Freenet enables anyone to have a
website, without space restrictions or compulsory advertising, even if
the would-be webmaster doesn't own a computer.
Freenet addresses these goals by providing a virtual space in
which to publish documents that is not tied to any specific machine.
Published information and Freenet's own internal data indexes are
replicated and distributed across the network in such a way that even
Freenet administrators don't know at any given time where all the physical
copies are located. Privacy for people browsing or submitting to
Freenet is protected by strong cryptography.
Java was a good choice for this project for at least two reasons.
First: the goals of the project put a heavy premium on having
compatible implementations on the widest possible variety of machines,
so Java's high portability is a dominating advantage. Second: the
nature of the project is such that the network API is important,
and Java has a strong one built in.
C is traditional for infrastructure projects of this kind that
have high performance demands, but the lack of a standardized network
API would have made porting a significant difficulty. C++ would have
had the same difficulty. Tcl, Perl, or Python might have reduced the porting burden,
but at a greater cost in performance. Emacs Lisp
would
have been painfully slow and totally inappropriate.
[an error occurred while processing this directive]
|
