Message-ID: <3BBF2B16.1DDB2A3F@csi.com>
Date: Sat, 06 Oct 2001 12:02:30 -0400
From: John Colagioia <JColagioia@csi.com>
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: rec.arts.int-fiction
Subject: Re: Sycamora Tree? What the...?
References: <2jmsqt4s5mqmq428af8sv0mfarqhhqe2h4@4ax.com> <QYMr7.5744$f5.377153@news> <jQNr7.24958$vq.4806597@typhoon.ne.mediaone.net> <3BB63FF8.B1758875@csi.com> <3BB64C6E.8B5406CF@attglobal.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 24.47.51.158
X-Original-NNTP-Posting-Host: 24.47.51.158
X-Trace: excalibur.gbmtech.net 1002383746 24.47.51.158 (6 Oct 2001 11:55:46 EST)
Organization: GBM Technologies Ltd
Lines: 77
X-Authenticated-User: jnc
X-Original-NNTP-Posting-Host: 127.0.0.1
Path: news.duke.edu!newsgate.duke.edu!news-hog.berkeley.edu!ucberkeley!news.maxwell.syr.edu!news.mailgate.org!zur.uu.net!bos.uu.net!nyc.uu.net!excalibur.gbmtech.net
Xref: news.duke.edu rec.arts.int-fiction:93239

"John W. Kennedy" wrote:

> John Colagioia wrote:
> > Apart from considerations mentioned by others, Java has a severe...identity
> > problem.  As far as I can tell (I tried briefly, a few months ago), you really
> > can't neatly isolate the JVM.  Java is as much a way of life, apparently, as a
> > programming language (and virtual machine, and security model, and...).
> That is a practical necessity for it to do its main job:  absolute
> portability of a very large subset of application programs.

I don't want to disagree, but I sort of have to:

a)  Java, despite all the layers added, is not absolutely portable, or even nearly
so except for a very small class of applications.  Small machines can't handle it at
all, most implementations are "specialized" (i.e., extended subsets of the basic
spec), and large-scale Java projects still require significant amounts of native
code (JavaOS, for example).  Security is an especially touch topic, as it is
implemented entirely differently in several places, yet is totally compliant.

b)  It is not at all necessary to heap this much "virtual equipment" to force
portability.  I happen to dislike Glulx, but I readily admit that it is probably
100% portable to any machine that can be forced to meet the memory requirement
(i.e., through compression or paging to disk or tape).

Not to mention the fact that--in the view of the user--absolute portability is bad.
Applications should not work "exactly the same" on every platform, because that
violates the basic premises of the platforms where the application did not
originate.  And if you are going to change the interface for each platform, you
might as well use one of the libraries (for C, C++, or any other language other than
MS-Win-"exclusives," really) that abstracts the interface API into something that
generates the proper code for the proper machine.


> But I'm not quite sure what you're saying.  The JVM can easily be
> decoupled from the rest, if you want to do it.  It just isn't normally
> done, because it leaves the language, like Algol 60, sans I/O.

That either isn't or wasn't (at one point) entirely true.  This may be out of date,
but I have been informed that the JVM analyzes code before executing and refuses to
run code not generated by a known Java compiler, in order to prevent "dangerous"
(i.e., self-modifying or dynamically-generated viral) code from contaminating the
system.

Additionally, keep in mind that the JVM reads everything from "class files," which
means that the JVM implementation either requires a hierarchical filesystem (further
limiting portability) or supply one of its own (at the expense of overhead).  That's
an ugly separation, if it can even be called a separation (as the hierarchy is
central to some of the security model).

It strikes me as very odd that there are no I/O instructions on the JVM, but in
skimming through the JVM spec now, I don't see any...


> > Plus, I never trust any language that has version numbers.  Compiler versions?
> > Sure.  Language revisions?  OK.  But a language should never have
> > "major-and-minor" designations...that shows a willingness to pull on underfoot
> > rugs and the like...
> Actually, the _language_ has had very, very few changes (the brief life
> of "private protected" scope and the introduction of private and
> anonymous classes are about all, up to now).  Changes in the language
> have historically been tracked by the version numbers of the Java
> Developers Kit, but that's a historical accident of administration and
> of popular parlance.

Alas, it's become popular parlance because Sun uses it.  And they use it, because
"Java 96" and "Java 97" seem odd, so the names have become software, which
is...icky.


> Now, the full Java run-time library has had a great deal of activity.
> But so has every living operating system within the same time frame.

Ah, but you see, Java isn't (supposed to be) an operating system, but rather a
programming language.  Most other languages have a fairly standardized library which
is extended periodically, rather than altered in real-time.


