JAVA Native Operating System (OS)
Michael Benson
[ Article crossposted from comp.lang.java,comp.os ]
[ Author was Michael Benson ]
[ Posted on 1 May 1996 17:14:30 GMT ]
How many people would be interested in seeing an operating system
based solely on JAVA?
This can be done in two parts, the first part is to write JAVA
aps that replace other operating system components while the operating
system is Windows, or System 7, etc. The core code for these aps would be
placed into the public domain.
The second part would take place after the components of the new JAVAOS
are written. It would be a basic kernel released for each operating system
with the code put into the public domain.
This is a plan that could create a universal operating system that is
NOT one-vendor specific and would allow it to be standardized in a way
similar to the way the IETF creates standards for the Internet.
Michael
--
Michael Benson
WWW: http://cne.gmu.edu/~mbenson
Email: mbe...@gmu.edu Whois: whois -h gmu.edu mbenson
Ross Finlayson
In article <4mgu73$2...@darkstar.UCSC.EDU>, mbe...@davinci.gmu.edu
(Michael Benson) wrote:
> This is a plan that could create a universal operating system that is
> NOT one-vendor specific and would allow it to be standardized in a way
> similar to the way the IETF creates standards for the Internet.
Oh wow, what a great idea! I've never heard of anything like this before :-)
(Although I remember once reading about a proposed OS called "Unix", but I
don't think it ever got implemented.)
Enough! I'm sick of all of this Java hype! Give me a break - it's a
PROGRAMMING LANGUAGE, for Christ's sake!
Ross.
Steven Fought
How many people would be interested in seeing an operating system
based solely on JAVA?
A new operating system could solve almost all the problems JAVA does,
and more, without having to take a 2-3 times performance hit over
native code. The OS defines all information routes into and out of
the address space, negating the need to reimplement the OS on the user
level (or the processor on the user level, which is what JAVA does).
The only problem a new OS couldn't solve is the ``one binary
distribution format.'' Vendors have been looking for such a thing for
ages because they've been using object code as a primative form of
encryption. Not only does this no longer make sense with normal
compiled programs because new tools to analyze and take apart object
code are becoming common, but with JAVA, I can reuse any companies
class libraries whenever I want because the interface is clearly
defined, and as far as I know there's been no move to add licensing to
JAVA any time soon.
Licensing wouldn't work anyway, because of the basic truth that all it
takes is one person to alter a class file to remove the licensing and
make it available to everyone. If it's going to be a JAVA, JAVA,
JAVA, JAVA world, those alterations will appear 24 hours after the
initial release, because security is inversely proportional to
popularity. If you doubt this, remember that UNIX bugs often exist on
most or all implementations, but those that require a minimal amount
of assembly language programming tend to be exploited only on SunOS
machines, because they're the only ones with a big ``pay-off.'' Over
time, this has led people to declare that Sun doesn't pay attention to
security as much as other vendors, which isn't really true when you
look at the nature of security problems that have come up.
This is a plan that could create a universal operating system that is
NOT one-vendor specific and would allow it to be standardized in a way
similar to the way the IETF creates standards for the Internet.
Every project starts out ``completely standardized.'' C++ started out
that way, and could very well be used that way today, because there's
nothing in C++ relating to specific implementations. What subverts
standardization is legacy code (programs, OSs, etc.) People who use
Windows want to be able to do OLE from JAVA, so they write a class to
allow it. People on the Mac want to be able to send AppleEvents, so
they write a class. All of these individualized classes appear years
before a universal facility that addresses the same problems could be
designed and agreed upon by the IETF, so by the time they release
their spec, there are millions of lines of legacy JAVA code that can't
be gotten around.
The only way to avoid this is to become completely facist and say that
your product will only interact with others in the ways that you
allow. You can then sit back and watch your project fail
(i.e. NeXTStep).
Steven
Vadim Antonov
mbe...@davinci.gmu.edu (Michael Benson) writes:
>How many people would be interested in seeing an operating system
>based solely on JAVA?
Well, as soon as you'll be able to explain how a different
language can make the system significantly different from
"traditional" operating systems.
(No, don't point at Unix/ó -- there was the new idea that the
OS code can be mostly hardware-independent; all sane OS-es
are built that way nowadays).
I would venture to guess that having semi-digested Java code is
not significantly different from having C source munched by an
obfuscator. And, then, there were FORTH, Smaltalk, DSSP and
other bytecodes before. Somehow compiled languages took over
(i can think of few reasons for that, related to the fact that
bytecode tends to lose quite a lot of information a native compiler
could use).
--vadim
Shankar Pasupathy
Such an operating system (assuming you could write one) would be too slow
to be of any use
Arun Sharma
On 7 May 1996 02:50:42 GMT, Steven Fought wrote:
Steven> The only problem a new OS couldn't solve is the ``one
Steven> binary distribution format.'' [...] but with
Steven> JAVA, I can reuse any companies class libraries
Steven> whenever I want because the interface is clearly
Steven> defined, and as far as I know there's been no move to
Steven> add licensing to JAVA any time soon.
But this portability comes at a cost, given that the java bytecode can
not be executed natively and needs _interpretation_.
--
Arun
Ketil Z Malde
The point of making a Java OS is probably dependent on what that's
supposed to mean. Implementing the OS in Java is going to make it large
and slow, requring everybody to program in Java is going to exclude a
lot of programmers, trying to translate other languages into Java byte
code is plain silly.
Having Java support in an OS' run-time system is a Good Thing, provided
it's put into a library or a daemon (see recent discussion on the
linux-kernel mailing list). Putting it in the kernel is rather
questionable.
That said, I think one of the basic stumbling blocks in modern OSes
(read: Unix :-) is the inability to have programs written in different
languages cooperate. Sure, you can link together .o files from
different languages, but it is mostly non-trivial -- name mangling, byte
order, etc. And how do you link together assembly, compiled programs,
interpreted programs, locally and remotely?
What I'd like, is a system that allows my C++ program to (transparently)
call Lisp routines (objects), that in turn call perl scripts, and so on,
as efficiently as possible.
One way to accomplish this, might be to have a clear interface
definition for every module (program, application, library, whatever)
with clearly defined «import» and «export» («use» and «public:»)
statements, that the run-time system can access. This way, I (or my
app) could query a module for public routines or data structures which I
could use -- hopefully even map into my app's address space, if
possible.
Is this what e.g. Spring does with it's IDL?
I've only superficially read about OLE, OpenDoc et al., and they seem to
be rather top-heavy and complex -- do they do this?
~kzm
peter honeyman
From ne...@lastactionhero.rs.itd.umich.edu Wed May 8 05:59:55 1996
Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by ftp.cse.ucsc.edu (8.6.10/8.6.9) with ESMTP id FAA08891 for <o...@ftp.cse.ucsc.edu>; Wed, 8 May 1996 05:59:53 -0700
Received: from lastactionhero.rs.itd.umich.edu by relay4.UU.NET with ESMTP
(peer crosschecked as: lastactionhero.rs.itd.umich.edu [141.211.63.110])
id QQaout20574; Wed, 8 May 1996 08:59:28 -0400 (EDT)
Received: (from news@localhost) by lastactionhero.rs.itd.umich.edu (8.7.5/8.6.9) id JAA15985; Wed, 8 May 1996 09:00:26 -0400 (EDT)
To: comp-os-...@uunet.uu.net
Path: honey
From: ho...@citi.umich.edu (peter honeyman)
Newsgroups: comp.os.research
Subject: Re: JAVA Native Operating System (OS)
Date: 8 May 1996 13:00:25 GMT
Organization: Center for Information Technology Integration, Univ of Michigan
Lines: 13
Distribution: world
Message-ID: <4mq5t9$f...@lastactionhero.rs.itd.umich.edu>
References: <4mgu73$2...@darkstar.UCSC.EDU> <4mmdqt$1...@darkstar.UCSC.EDU> <4mno8k$9...@darkstar.UCSC.EDU>
Reply-To: ho...@citi.umich.edu
NNTP-Posting-Host: gloom.citi.umich.edu
Status: RO
Ketil Z Malde writes:
|> I think one of the basic stumbling blocks in modern OSes
|> (read: Unix :-) is the inability to have programs written in different
|> languages cooperate. Sure, you can link together .o files from
|> different languages, but it is mostly non-trivial -- name mangling, byte
|> order, etc. And how do you link together assembly, compiled programs,
|> interpreted programs, locally and remotely?
the way unix programs interact is not through linking, it's through
pipes. the languages in which these programs are written is not at
issue. (well, ok, they're all written in c, but you get the point ...)
peter
Steven Fought
What I'd like, is a system that allows my C++ program to (transparently)
call Lisp routines (objects), that in turn call perl scripts, and so on,
as efficiently as possible.
One way to accomplish this, might be to have a clear interface
definition for every module (program, application, library, whatever)
with clearly defined +import; and +export; (+use; and +public:;)
statements, that the run-time system can access. This way, I (or my
app) could query a module for public routines or data structures which I
could use -- hopefully even map into my app's address space, if
possible.
Is this what e.g. Spring does with it's IDL?
I've only superficially read about OLE, OpenDoc et al., and they seem to
be rather top-heavy and complex -- do they do this?
OpenDoc is primarily a compound document format. OLE is basically
what you're describing. CORBA and Distributed OLE take what you're
describing to the next step, allowing interactions between objects
distributed on different machines.
Steven
David Arnold
<ke...@fossekall.ii.uib.no> writes:
What I'd like, is a system that allows my C++ program to (transparently)
call Lisp routines (objects), that in turn call perl scripts, and so on,
as efficiently as possible.
One way to accomplish this, might be to have a clear interface
definition for every module (program, application, library, whatever)
with clearly defined «import» and «export» («use» and «public:»)
statements, that the run-time system can access. This way, I (or my
app) could query a module for public routines or data structures which I
could use -- hopefully even map into my app's address space, if
possible.
this is exactly what ILU (Inter-Language Unification) does. it
supports both same address space and distributed objects. it's very
cool.
try
<ftp://ftp.parc.xerox.com/pub/ilu/ilu.html>
-- David Arnold ,=================================================
=================' +617 3654310 (voice)
CRC for Distributed Systems Technology +617 3654311 (fax)
University of Queensland arn...@dstc.edu.au (email)
Australia <http://www.dstc.edu.au/> (web)
C++ compilers rarely optimize for the joy of programming - lwall
Dominic Giampaolo
I'm sick of the Java hype too, but I think this is a serious proposal.
Even the AT&T Bell Labs (now Lucent) folks are getting into the game
with a Plan 9/Aleph derivative:
http://inferno.bell-labs.com/inferno/infernosum.html
The summary makes it sound kind of cool to me but then again I tend to
like new, off-beat things.
--dominic
peter honeyman
Bryan O'Sullivan
In article <4n05cr$n...@darkstar.UCSC.EDU> d...@be.com (Dominic
Giampaolo) writes:
d> Even the AT&T Bell Labs (now Lucent) folks are getting into the game
d> with a Plan 9/Aleph derivative:
d> http://inferno.bell-labs.com/inferno/infernosum.html
d> The summary makes it sound kind of cool to me but then again I tend
d> to like new, off-beat things.
It certainly seems interesting, but then there is such a paucity of
real information on the Inferno web pages that it is difficult to draw
many conclusions.
If the comparison between the Limbo (Inferno's programming language)
and Java languages is anything to go by, I suspect that Lucent's hype
for Inferno contains an adequate share of silliness. In particular,
the Limbo-versus-Java comparison contains the following points of
questionable veracity and relevance:
- "When a Limbo program begins execution, it has a fixed interface to
these [i.e. network and security] services and is therefore
inherently more portable than any language-only solution"
The standard Java libraries are an integral part of the Java system,
have already been ported to many platforms, and provide broadly
similar functionality to what it seems Inferno gives to Limbo. As
far as the programmer is concerned, it does not matter whether a
facility is provided by the operating system or by a library.
- "Java is derived from C++ and uses the object model to provide
interfaces to system services. Limbo avoids the complex
object-oriented features of C++ [...]"
This implies that Java's object system is as unwieldy as that of
C++, which is rather far from being true.
- "For Limbo, concurrency and communication are an intrinsic part of
the language and the virtual machine, and are used extensively in
the programming model"
In Java, concurrency is built into the language (the above quote
implies that it is not), while communication across address space
protection boundaries is provided by the libraries. It is entirely
conceivable to me, mind you, that IPC in Limbo might be more
pleasant than in Java (especially if it is based on the channel
mechanism in Alef). However, Limbo's channel-based IPC looks
distressingly language-specific, while Joe (another method for
gluing networked programs together under Java) has the benefit of
talking to any CORBA ORB (and, by extension, anything that supports
Network OLE).
- "Limbo has more general pointers, without sacrificing safety"
This is of no advantage to programmers.
- "Limbo's garbage collector has constant overhead, so its operation
does not conflict with real-time constraints"
This is an irrelevant implementation detail, and I believe it is
generally known that the Java people aim to improve their garbage
collector. Granted, if Limbo's runtime already provides this, that
may be small temporary win.
- "An application can configure dynamically, loading only those
modules needed at any moment; it may load and even unload modules as
its environment or execution dictates"
This feature is independent of the language in which a system is
implemented. In addition, the Java runtime loads class files on a
by-need basis. It does not, however, provide the questionable
facility to manually unload modules; this cannot be done safely
unless such modules are garbage, in which case it could be done
automatically.
Other points worth mentioning:
- Limbo's runtime uses reference counting garbage collection. Unless
it uses deferred reference counting or something similar, I fail to
see how it can have constant overhead in any locally meaningful
sense. In addition, unless the runtime people are being clever,
cyclic data structures will cause havoc in Limbo programs.
- While it may be that the Dis VM is more amenable to straightforward
runtime compilation for register-based machines than the is Java VM,
it is easy to reconstruct a call graph from a stack-based
instruction stream and generate efficient code for register-based
machines from it.
In summary, don't believe the hype.
I would be interested in having any misapprehensions of what Limbo and
Inferno do and don't provide corrected by someone from Lucent.
<b
--
Let us pray:
What a Great System. b...@eng.sun.com
Please Do Not Crash. b...@serpentine.com
^G^IP@P6 http://www.serpentine.com/~bos
Carl Staelin
Java does not have to be slower than native code; there is at least
one public domain project developing a byte-code to native compiler
that will compile java byte-code on-the-fly. This will allow java
applications to run at native speeds. Of course, the fly in this
ointment is the compilation overhead, but if applications are
long-running or re-used often then this overhead is negligible.
For more information on the Kaffe byte-code compiler project see:
http://web.soi.city.ac.uk/homes/tim/kaffe/faq.html
Carl
--
-------------------------------------------------------------------------------
Carl Staelin
sta...@hpl.hp.com http://info.hpl.hp.com/people/staelin.html
o) (415)857-6823 FAX) (415)813-3152
-------------------------------------------------------------------------------