Java was developed by Sun and at present (mid-2002)
eclipsed only by XML as the current Big Thing. Source
code is compiled to machine-independent bytecode, which is
then either interpreted, or compiled to machine code on
the fly, by a Java Virtual Machine (JVM) on a particular
platform. The main interest to astronomy might be in
developing machine- and architecture-independent
interfaces either to codes or archives. It's also, I
think, of use as a stepping-stone to C++, since its
object-oriented features are less obscured by syntax than
they are in C++. A very good textbook, written (you won't
be surprised to guess) by two of the language's authors,
is The Java Programming Language
[arnold98]; once you've mastered the
basics, there's a good deal of helpful advice in
Effective Java [bloch01].
There are numerous resources at Sun's Java site at
<http://java.sun.com>
.
Java is a mixture of an interpreted and a compiled language. Java source code is compiled by the Java compiler into bytecodes, which are then interpreted by a Java Virtual Machine. These bytecodes are low-level, but architecture-independent so that, in principle, only the virtual machine and its runtime need to be ported to a new machine, whereas the code should be completely portable. This does not work quite as well in practice as it does in principle, but it does mean that Java is not too far off the ideal of run-anywhere code.
Since Java bytecodes are ultimately interpreted, Java programs have the potential to be rather inefficient. However, just-in-time compilers (JIT), which analyse running code and optimize the most heavily-used parts, and similar developments, should help the situation improve in the future. This is possible because JITs have access to both the program source code and the running program, and so can combine the features of both an optimizer and a profiler, and thus optimize more aggressively than a traditional compiler could. This, combined with Java's good built-in support for different platforms and for resource-discovery, means that, possibly somewhat surprisingly, Java has been suggested as a suitable language for high-end codes. The Java Grande Forum is concerned with investigating and promoting developments in this area.
Note that it is relatively easy to write slow Java (for
example, adding Strings is a lot slower than
using a StringBuffer; input and output streams are not
(extensively) buffered, so if you have a lot of I/O, you
would be well advised to use
Buffered{Input,Output}Stream
objects wrapping
your I/O objects; small-object creation is extensively and
increasingly optimised, but it's still not dirt-cheap, so
look out for that in a small loop). That means that using
a profiler (see Section 2.5.1) is particularly
important. However, with Java, that's easy, because
there's one built in to the JVM. Give the option
-Xrunhprof:help
to find out how to invoke it.
For example:
There's quite a lot of information in here (and the file format is under development), but as with all profilers, you'll see a list of the number of times various methods were called: the ones at the top of the list are the ones where the program spent most of its time, so work out why, and concentrate on making them faster. Ignore the rest.java -Xrunhprof:cpu=samples,file=myprog.hprof myclass
Java is still developing. At present (mid-2002) Java
1.3.1 is long in the tooth but stable. Version 1.4 is in
beta, and on the point of being released properly; it
includes a few changes to the language, most noticeably
the inclusion of an assert
construct.