Message-ID: <3BC8370A.E8BBF6D@csi.com>
Date: Sat, 13 Oct 2001 08:43:54 -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: JVM for IF? (was 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> <3BBF2B16.1DDB2A3F@csi.com> <3BBF7E05.8CB2C92E@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 1002976611 24.47.51.158 (13 Oct 2001 08:36:51 EST)
Organization: GBM Technologies Ltd
Lines: 153
X-Authenticated-User: jnc
X-Original-NNTP-Posting-Host: 127.0.0.1
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!peer.news.zetnet.net!newsgate.cistron.nl!newsfeed.online.be!zur.uu.net!bos.uu.net!nyc.uu.net!excalibur.gbmtech.net
Xref: news.duke.edu rec.arts.int-fiction:93533

"John W. Kennedy" wrote:

> John Colagioia wrote:
> > 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.
> JavaOS isn't an application program.

This is true, in itself.  However, it stands as one of the largest and most "general"
caches of Java code, doing things that many application programmers want/need to do (or
will, once their requirements grow beyond client-side interfacing).  And doing many of
those things requires non-Java, non-JVM code to work.


> For the rest, no, obviously small machines cannot handle Standard Java
> -- which is why there is a special Java subset, which has been
> implemented on "machines" as small as smartcards and signet rings.

First, "special Java subsets" aren't Java, and certainly aren't as widely distributed.  I
also doubt that the standard JVM is used.

Second, a small physical size does not imply a "small machine."  If you hack off the
ceramic shell, I believe one can cram a 486 with a couple of megabytes of RAM or ROM into
a signet ring.  That's hardly small, in my opinion.

[...]

> > 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.
> Except that there isn't any such thing -- at least not a generally
> accepted one with a reasonably secure life expectancy.

There's a reason for that, too:  Having one wouldn't help anybody except people doing the
relatively trivial applications that are most normally seen in Java.  If there were a
significant demand, someone would have written a stable one, by now--mainly because it
wouldn't be all that difficult.

[...]

> > > 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.
> No, it checks for dangerous code per se, using program-proving methods.
> It doesn't care about the source of the code.

Although (not related to IF; just brainstorming, here) it does care about the source
inasmuch as it will disallow any source program that tries to do anything "dangerous,"
which eliminates a handful of elegant, but special purpose algorithms, as well.


> > 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).
> The JVM reads class files from anything that will do the job.  Most
> modern class files are read from JAR files, which are, essentially, ZIP
> files.

Yes, I have the misfortune to know quite intimately what JARs are made of.  This would be
simulating a hierarchical filesystem.


> Java run-time IO does assume a generally Unix-like file system.  But so
> does virtually every other language nowadays, except for older languages
> like FORTRAN and COBOL that effectively demand an external file
> definition, and pretty much any system that supports a C compiler has
> some means of producing the appearance of Unix-like I/O.

I know of no language that assumes anything from the operating system.  About the only
thing the C standard library assumes (like Java, C doesn't do file handling on its own, as
you know) is that there are these funny things called "names" and "permissions."  Well,
actually not.  It assumes (or simulates) names.  Permissions are more for the programmer,
when you get right down to it, than they are for the operating system.

Java, on the other hand, needs itself stored in a hierarchical format, before you even GET
to the file-handling routines.

[...]

> Since all I/O is done by subroutine (method) calls anyway, it's just as
> easy to make them native-mode methods.

"Just as easy"?  I disagree.  From my experience, it's more like "far easier, because it's
damn hard to do it in Java."

[...]

> > > 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.
> The name "Java" effectively refers to:
>   a language,
>   a virtual machine,
>   a run-time library, and
>   a virtual operating system.

Java is also a security model (which isn't directly related to any of these, but still
somehow intertwined in odd ways).  And, as with all major languages, it is also a
"society," to a certain extent.

I could also argue that it's a collection of non-language-related technologies, like
Garbage Collection and the like, but I'll play along on that point for now, and pretend
this is part of the language.


> It is unusual that the run-time library includes every aspect of the
> virtual operating system, but this means that it is not necessary to
> rely on operating-system-dependent calls

Except that, first, this could be decoupled better, and second, it's still necessary if
you need to do anything that the library-builders didn't consider (or didn't think through
completely).  I have "neo-legacy" code at work that needs to do this for some security
routines.  It's not fun.


> (especially important during an
> era when 90% of computer owners are fool enough to rely on an operating
> system with a hostile and intentionally [tactically] unstable API).

Funny...I actually have written thousands of lines of C code which extensively use the
Win32 API that's been running fine since late Windows 3.1.1 (with "Win32S" installed).
The only changes I've made in that time were to the file handling calls, and that was only
to use the "new look" dialog boxes.


> I wish Java were better than it is.  But right now I intend to use it
> wherever possible for everything that isn't more appropriately done in
> PERL or in some domain-specific language (such as Inform), because, as a
> programmer, I find Java my best general weapon to escape from the
> tyranny of Microsoft.

Well, anyone using a "sharp language" in the coming years--or the MFC libraries at any
time--will pretty much deserve whatever they get.

In the meantime, I'll probably stick with ANSI C and the Win32API (when graphical
interfaces are necessary--thankfully not often in my line of work) for most "real" work.
Although, even though I haven't finished reading up on it, Ruby looks like it has
significant potential for doing what I want.


