[1472] in java-interest
Re: Systems Programming Oriented Java
daemon@ATHENA.MIT.EDU (Chuck McManis)
Tue Sep 5 18:42:57 1995
Date: Tue, 5 Sep 1995 09:44:41 -0700
From: cmcmanis@scndprsn.Eng.Sun.COM (Chuck McManis)
To: ramsdell@linus.mitre.org
Cc: java-interest@java.Eng.Sun.COM
>I propose the creation of a new dialect of Java, called J, intended
>for systems programming.
This should not be necessary, if you consider "C" to be the assembler
of Java it should be possible to write an OS in the current Java simply
by adding a few classes that are implemented in C (like portions of UNIX
are implemented in assembler, etc)
>J would be suitable for systems programming because J programs should
>require nothing more than a C-like runtime system.
This sounds kind of like you want a single file executable, I don't know
if that is what you intended to mean or not, if not then ignore this
comment:
Most OSes today are dynamically configurable. SVR4 based systems use loadable
modules to add system calls and device drivers, Windows uses DLLs and VBXes,
the Mac has "inits" etc. Java has "classes". Java programs "feel" a bit
ungainly on hosted systems (like UNIX) because when it was originally designed
it was the OS, not running on one. If you imagine the 'java' program as the
kernel, then an "application" is simply the initial class you invoke. Its
somewhat forth like in that writing classes adds new features to the system
which can then be invoked by other classes etc, etc.
> ... In particular, J
>programs should be runnable without the use of automatic storage
>reclamation, and they may explicitly free objects.
As a C/Kernel hacker from the "early" Sun I share your mistrust of
garbage collection systems, however we have some very bright folks
(Bill Joy being one of them) who are convinced that GC based systems
are as viable for OS work as the current alloc/free schemes. The
assertion is that GC systems are reaching a level of maturity that
optimizing compilers have, that is to say they do more of what you
want and less of what you say. :-)
>J could be used to implement a Java bytecode interpreter. With a
>little foresight, one could write and debug most of the interpreter as
>a Java program. A few classes would need new definitions before the
>interpreter is presented to an J compiler. Maybe the J compiler will
>generate C, C++, or Objective C, which will then be translated into
>machine code.
Don't confuse the bytecode interpreter with Java. Think of the interpreter
as a chip, a piece of hardware. Would you expect that the design of the
SPARC chip was written in C because the OS you were going to run on that
chip was to be written in C ? I wouldn't, I'd still define the chip in
VHDL since that is more amenable to expressing the hardware. The "interpreter"
is just the Java CPU. And I would like it to be so concretely specified that
I could implement it just once in native assembly code and then treat it
like a black box. However for portability reasons we stick to C.
[PreScheme reference deleted]
Thanks for the pointer, looks to be great reading.
>Next time you write a complicated program that must use a C-like
>runtime system, think how nice it would be to develop that program in
>a Java environment.
It is a lot more fun than writing in C.
--Chuck
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
