\title{Java, Java}
\author{Malcolm Clark}
%\newcommand\BV{Baskerville}
%\newcommand{\url}{\texttt}
%\newcommand{\TUB}{\textsc{Tug}boat}
\begin{Article}
%\section{Java}
\noindent
January 30th, Queen Elizabeth \acro{II} conference centre, just off
Parliament Square,
high security at the door, thousands of suits
(so that's what happened to all those delayered \acro{IBM} guys),
few women, even fewer
pony-tails. We start 20 minutes late (surely not technical
difficulties? no, it appears we're letting the late comers
get through security and up to this floor). Dry ice in the hall,
synchronised flashing lights (is this a disco, or an awards presentation?),
sub-Star Wars music. The audience of a thousand are reverentially
hushed except for the bleeping
of personal telephones. The lights go down, the music up;
Robert Young-Johns (one of Sun's \acro{VP}s)
bounds onto the stage, wearing the Java uniform --
a cute black shirt with all the right logos.
Good move: they are clearly not suits, but  still projecting
an `acceptable' corporate identity. He apologises for the
hype: `Java will not cure all known ills', but appeals to
our imagination, citing an examples from home banking (yawn),
Dolly Parton and Jupiter.

Sun now score a small point by managing to convince
the Minister for Science and Technology (did you know we
had one?), one Ian Taylor \acro{MP}, to start the conference off.
Apart from an interesting political incorrectness (perhaps
understandable, he is, after all a Tory minister), he was
adequate. At least he seemed aware of the Internet, and
he was also aware that the digital revolution needs to get
out to rural areas too, citing the freeing up of radio
spectra which could offer \acro{ISDN}-like data transfer rates.
He was also looking forward to a future of smart cards
and kiosks (and even interworking between government departments).
He stayed for the next talk then strode off with his
apparatchik hot on his heels.

Bob Sproull next: this is more like it. This man is seriously
worth listening to (Newman \& Sproull, Principles of
Interactive Computer Graphics). We knock through a wave diagram
(the waves are mainframes, minis, pc plus proper user interface, and
the network: they are as much focus shifts as waves). The man
says `paradigm'.\footnote{You can
easily identify those who flowered in the 60s and 70s: they
know how to say `paradigm', and aren't afraid to.} I like him.
He tackles some of the worries: does the Internet  have stable funding?
In his view it has more stable funding than some of the governments
who once funded it. They could disappear tomorrow, but the Internet
would still be there. What's wrong with the Web?
He cites its lack of
interactivity (sic), extensibility, and security, but lauds its
`publish once, read anywhere' democratisation.
What's the answer? Java of course. Java applets (little applications)
can be downloaded and can provide the interactivity we long for.
The interaction is at the client end, so we aren't shipping
information backwards and forwards from client and server.
Ah you say, I don't like the idea of downloading a program
over the Internet to run on my machine; that's just asking for
trouble. Obviously the Java team thought about this. What happens
is that the applet runs on a Java virtual machine. You get your bit
of code (platform independent) and the Java virtual machine interprets it.
That way you can insist that the applet has access to only a very
few facilities: it should `do no harm'. For example, applets cannot
write to files on the client, and cannot access arbitrary bits of
memory or files (your credit card details are safe). There's a bunch
of other stuff to ensure that this is going to be secure, some
bound in the structure of the programming language, and some
in its operation. The Java language specification is, in normal
Sun style, open: the specifications are published. They intend
to offer `compatibility' tests and performance guidelines
(claiming along the way that interpreted Java can be as fast
as compiled C++). In this way they hope to avoid the Balkanisation
that is Unix (his phrase). Later, I asked Sproull how confident he was
that a similar `Balkanisation' would not dismember Java, wondering
what would happen when Netscape or Microsoft decided to add their
own extensions (think of \acro{HTML}, for example). He said he was optimistic
rather than confident, but that there was clearly an advantage to
a level of \textsl{de facto} standardisation brought about by
a high level of interoperability, really hoping that
the momentum was sufficient to prevent too much deviation.


The history of Java is interesting: it was not envisaged as
an Internet killer app, but as a way of controlling domestic
appliances from toasters to \acro{VCR}s. Or maybe even your doorbell
(if I go back to a talk I heard recently by Andy Hopper of Olivetti
Research Laboratories). In passing you can begin to see why those potential
4,294,967,296 \acro{IP} addresses start to look limiting. We don't need
one for each individual on the planet: we need one for each connected
device on the planet (or off the planet: no doubt Galileo could have
had an \acro{IP} address, just as the Shuttles do). It was designed to be a
language for embedded systems,  imposing the constraint that it
had to be pretty compact. Sun have been maintaining
that the network \textsl{is} the computer for some time. The network really is
essential to the workings of this computing. Given its platform independence
(or `neutrality', as the current term seems to be), Sproull could claim
that we were moving to a `write once, run anywhere' range of apps.

After coffee (I would have prefered to say `a steaming cup of Java',
but no, imagination did not stretch to the caterers), Oliver Morton
of \textsl{Wired} took the stand.

This was a surprisingly erudite, literate and interesting
talk. I hadn't really expected a journalist (even one at
\textsl{Wired}) to be like this Pony-tail. He talked about something
I understood -- the Cambrian period. His suggestion was that
there is a parallel between evolution of lifeforms and evolution
of programs. He suggested that it was back in the Cambrian when
diversity exploded, and that we date biological variation
from then. He suggested that the parallel `event' now is networking,
which will lead to the same sort of explosion of riches and exploitation
of `niches'. I don't really buy argument by analogy (a viewpoint
which goes back a long way), but the talk was emminently enjoyable,
plausibly relevant, and the \acro{AV} work was excellent! Instead of
fixed `slides' prepared in some PowerPoint-clone, where the
excitement lies in the dissolves and fades, this was a slick (non-perjorative)
presentation, where the text on the screen moved around in a way
which contributed and enhanced what he had to say. It wasn't really
multimedia, but it showed a real quantum leap from `ordinary'
presentations. Of course, this stuff is a blow to me. Usually
I scribble down what's on the slides and then go back to listening
to the talk. Not possible.

Matt Reid, another Sun manager took us on `The Java experience',
bringing to the podium specimen Java developers. This array of talent
included Charles Ashley (Matrix Publishing), Alan Slater (Orbital
Technologies), Per Gunnar Osteby (Applet UK), Alan ?? (Knowledge
Media Institute -- the Open University's newest venture) and Gary
Bullock (Parallax). A good range of things in there, from Web
enhancement through to good interactive applications, telepresence
and the word `Javatise'. Then we wheeled on a star: Miko Matsumura from
\textsl{Hot Wired}. He told us he had  already addressed audiences on
Madison Avenue and Silicon Valley, so we knew he thinks he's good:
he probably is too. There is something about these assured
20-something year olds, so completely in control, and at the leading
edge which makes me want to retch. Envy I think it's called.
The example he showed included an `avatar'. That's interesting, since
it suggested he'd read Neal Stephenson's \textsl{Snow Crash}, which
I predict is an excellent predictor for much cyberspace development.
He ended by telling us he is the first Java evangelist. I reached
for my bell, book and candle.

The afternoon split into three streams. I took the stream
which contained my first jolt of Java and more Bob Sproull.
Simon Roberts, from Sun's Educational Services taught
us how to write an application in the Java language in
just 45 minutes. No, that doesn't mean it takes only 45 minutes
to learn Java. It just means he led us through it,
assuming that we were happy with C++ already (I wish!). Java
borrows its syntax mainly from C++, but just to confuse there
are some syntactic differences: it is largely object oriented,
and where it differs most from C++ is in any part of that language
which lets you effect strange and unsocial things -- like
pointers and overloading of operators. It also simplifies by
permitting only single inheritance. I ended up more confident
that Java was quite coherent and had a lot of thought hours
behind it. It also seems to be the programmers' revenge on the
Internet. Let me explain. In the good old days, the Internet
was the preserve of the hacker (again, in a non-perjorative sense);
you had to know a bit about networks, be able to incant in Unix,
have a smattering of some obscure programming language (C, C-shell,
grep, Perl or whatever). This was when the Internet was free and
easy, when the Acceptable Use Policy said `no commercial use',
when people shared programs, and all was sweetness and light (this
is a nostalgic view). Then along came the Web with its trivially
simple \acro{HTML}. Anyone could use the Internet, and anyone could provide
information for it. And at the same time, it exploded into commerce,
politicians started pontificating, and frankly, it
got rather non-elitist! Along comes the next step (apologies to
Steve Jobs!) -- Java. This will separate the men from the boys. Only
the traditional propellor heads will be writing the code, but yet,
it's what the Net needs. Control has been restored to the anarchists.
Well, maybe. In fact I suspect we'll see application environments
where most people can create Java applets without getting their
hands dirty. But for a while the programmers will be leading.

Back to Sproull: he's talking about Commerce and Security. To be honest,
he isn't really into commerce, but he dutifully covers the areas
he thinks are going to develop by breaking commercial
uses of the net into four areas:
selling and advertising (for example, find the product: this can be
exemplified by the use of directories); make the sale (here there is great
weight on the security of transactions and the confidence with which payments
may be made); fulfillment (where orders might be filled entirely
digitally, and where standing orders might also be arranged entirely
automatically); customer service (which might expand into relationship
management where the supplier advises the customer of other related products
or services, or upgrades, enhancements, etc.). In other words we are looking for
added value, as we would expect.

%The Web browser can provide images, forms and (now) secure sockets, but the
%incorporation of Java applets can take this further to give active content,
%uniqueness and to control the presentation far more. In fact, Sproull seemed to
%be hinting that the retention of corporate identity (or brand differentiation),
%one of the banes of the Web, could be achieved through Java applets. He didn't
%exactly say it, but he implied that applets could ensure that pages looked the
%way that their designers intended (as Acrobat will do).

Security is one of the major issues on the Internet. There is a lot of loose
talk about how insecure it may be, usually based on anecdotal evidence which
evaporates when tracked down to its source.
%People who happily provide their
%credit card details over the telephone are often the first to tell you how
%insecure the Internet is. They should know!
But taking it further, to the prospect
of downloading an applet to run on your machine, needs careful thought.
As I have commented already, considerable thought has gone into Java to make it
secure. Sproull identified a number of areas that we think about within the
general heading of security. We think of `benign' programs: those that `do no
harm'. The language restrictions of Java are supplemented by the fact that the
Java virtual environment checks the byte code of the downloaded applet to
ensure that it has not been tampered with en route. Add to this that an applet
can only call another applet from the  server which provided the calling
applet, and, in fact, may only contact that source server and no other. There is
also a security manager on the client which restricts access to the client's
resources. If you are dealing with a `trusted' server, the browser's\slash
client's policies may be relaxed. For example, if you were running an Intranet
within a department or enterprise, you could conceivably allow the applet to
read files and ship the details around. Spreadsheet applications or other
databases could be candidate applications. But in an `open' environment like
the Internet, you would be less likely to take this option.

Privacy on the net is of course possible, essentially through encryption based
on secret keys. This makes key management an issue. If you have various plastic
cards, each with their own \acro{PIN}, you will know how difficult it can be to
remember each one. Many people will resort to writing down the \acro{PIN}s or
keys, with the result that security is compromised. However, this is a
reasonable human response to an unreasonable expectation. With public key
cryptography, whose details are well-known, though whose implementation is the
subject of \acro{US} government restrictions, we may encrypt with a
public key and
decrypt with our private key. Provided the key is big enough this is pretty
secure (unless your adversary happens to have access to a supercomputer or a
farm of workstations). In any case it is possible to attack these schemes,
principally by replay attacks (where, for example, you copy the transaction to
buy a Porsche over the net, replay it, and intercept the second delivery),
the man in the middle ploy (where you pretend to be the supplier and therefore
acquire the essential information which is then used surreptiously), or perhaps
by analysing the traffic very carefully to identify useful information which
is then sold or used. Much of current communication depends on trust: that
does not mean that the transactions have to be completely accurate: provided
we have reliable and well-understood remedies for mistakes, we are usually
happy. In general terms we have to balance the risks and the security:
high levels of security usually involve high levels of inconvenience.
At present Java tends towards security.

So there. What's it got to do with us? It is not inconceivable that \TeX\
itself could be written in Java. But who would want to ship that behemoth
around just to run through a document? Had \TeX\ ever been modularised, this
might have been viable, but its monolithic structure militates against this.
What then of the helper applications -- the viewers or the printer drivers?
Possibilities. Remember that the `applet' (more like macro-applet) need only be
written for a single virtual platform. This may be more difficult in the first
instance, but in the longer term it has to be worthwhile. Future proofing is
in-built. I go back to the notion my avatar promulgated in \BV\ 5.3 --
distributing \texttt{.dvi} but this time having a Java applet be the viewer or
printer. Use once, discard. Not an issue for us, since we all have a good
viewer, but useful for the disenfranchised. The drawback lies in the fonts, but
as suggested then, Adobe's Multiple Masters will do nicely.

Did I mention that Java won't run on Windows\,3.x? or on Mac
\acro{OS}6? You need Windows\,95, \acro{NT} or the Mac's Copland. So
throw away those slow old machines. But wasn't that always the story?

\end{Article}