leJOS.Imported @ jos.sf.net

JannuxSpecification

Article contributed by GilbertHerschberger.

Introduction

Is it possible to create a simple demonstration of JOS with existing components? Here is the process:

Take an off-the-shelf Linux distribution,
Configure XFree86,
Add a Java Virtual Machine from blackdown, Jaffar or IBM,
Mix a couple of shared objects written in C/C++ for Linux,
Stir in a generous helping of custom code written in Java,
Bake for a few minutes on a Intel '486 processor,
And enjoy!

Sure, I understand that it won't give us everything we're looking for in a Java operating system. But, it's a good start.

P.S: May be we can use OSkit + Kaffe VM to start de SimpleJOS

A big part of the Java API must be rewritten in a cleanroom environment to keep JOS free. The classpath project is trying to do that. -- GilbertHerschberger (21 June 1999)

Although it should be possible to use Classpath for SimpleJOS, I don't know if it can be used for the JOS class libraries. The main problem I see is the use of native code in some of the packages (java.io., java.net., etc), will JOS support native code? Also, how do you map from a java driver object to a java.io.File or java.net.Socket object?

-- RobertFitzsimons (23 June 1999)

We must be methodical. We must list each class in the Java API that needs to be implemented for each JVM. When Sun Microsystems created a short list of JVMSpecificClasses, they made the assumption that there would be native code. If at first, we assume there is going to be native code, we can methodically prove we can do everything without it. If JOS must support a JNI API, there must be something "native" to work with.

Your example of java.io.File and java.net.Socket only just the beginning. -- GilbertHerschberger (23 June 1999).

IMHO using Linux isn´t cool enough for you ultra-conservative-corporate-people[tm] :)

What about using multiple VMs connected via Jini? IMO this is the way to go.

Thus Jos fits in a little black box and uses your TV, Hifi and toaster for IO, without rewriting all the code. We´ll have to develop custom services for video, audio, storage, etc. - that´s all. We´ll be able to write Jos in an existing VM and add the Jos Kernel as needed. Much like GNU (actually I think that the GNU Hurd might be a good platform to place a JVM as a kernel server).

MarkAMeyer, 28. Jun 1999

I agree with you Mark. Jini seems like a great design (architecturally). It may end up being way too slow but the idea of using a multiprocessing kernel to create separate jvm's communicating via jini is very appealing. Even better, for device drivers written with a Jini interface, you can decide on a case by case basis how much of the driver is in native code, and how much is in java. You can also very strictly control how much java you need (jini should allow you to write some of the "driver jini services" with little or no jvm/java overhead).

IainS, 05, July 1999

I have been fiddling with a list of Debian packages that would be required/desired on a JOS dev system but haven't had the resources (short of small hard drives) to try it out yet. The idea would be to install debian base (potato) apt/dpkg in the base packages including the jdk-1.1 runtime and dev tools and X, and then throw Swing and FreeBuilder on top (which are not debianized yet afaik).

Possible options include the beta jdk1.2 for linux, Berlin, Shark, or doing the whole thing on top of a bsd, or even GnuMach. I only looked at Debian so much because most of the software is already available, the package system makes it easy to slim the system down or scale it up to add your favorite dev tools, and perhaps because FreeBSD hasn't been nice to me lately :(

OBSD can use an FBSD jdk, so it could be used as well for the more paranoid among us. A linux Jvm compiled to fbdev would eliminate X from the picture..

Thoughts? I hope to have a chance to mess with this hands on next month (July).

-adric (aka BenKnowles)

A viable platform must support Java native interface (JNI) and real OS processes.

...the idea of using a multiprocessing kernel to create separate jvm's communicating via jini is very appealing. - IainS

The best architecture I've seen so far is a multiprocessing kernel, separate JVM's communicating via network inter-process communication (like TCP/IP). Each JVM supports threads. Each JVM is a distributed computing domain. Even JINI(tm) runs over TCP/IP. For more information, see also JustJOSProposal and OneProcessOneVM. -- GilbertHerschberger (8 July 1999).

Linux isn´t cool enough for my ultra-conservative-corporate-people[tm]. That's the message I'm reading loud and clear. Yes, Linux works inside a server closet. Yes, our technicians love it. Yes, there may be lots of free software available.

While the Linux kernel, Samba, Apache is high quality software, a lot of Linux software follows in the look and feel of UNIX(tm) which is 30+ years old. There's no way we're going to install Linux as our corporate desktop.

The Linux community can make the transition into the next platform. We know that neither 100% Pure TUI nor 100% Pure GUI is the best answer. We know that neither 100% Pure C/C++ nor 100% Pure Java is the best answer. The next platform is mostly Java with a little C/C++ mixed in.

My clients haven't changed much in the last fifteen years. They want today what they wanted fifteen years ago. What do my clients want? They want high quality software. High quality software is scarce; but, they're willing to pay top dollar for it.

My clients don't want poor quality software at any price. Poor quality software is abundant. It is everywhere. They use poor quality software reluctantly, when they have no other choice.

I am convinced that the successor to Java-Linux (hopefully JOS) will be the killer platform. With a high quality OS kernel, multiple JVMs running in separate OS processes, it becomes possible to write the kind of high quality applications my customers want. -- GilbertHerschberger (8 July 1999).

CliffordSaeseman is working on Jester, a platform compatible with SimpleJOS. We ask Clifford to let us know more about Jester and when it's ready for download.

With a non-optimized architecture, we can build a working version of JOS.
We bypass a long discussion of license issues because SimpleJOS is distributed under the GPL/LGPL license because Linux and XFree86 are.
With a functioning version of JOS, we can build upon that platform to refine the kernel interface.

Java-Linux may or may not be the ultimate platform. Only time will tell. As far as rewriting an OS kernel and reinventing all those device drivers that Linux already has, that's not the fastest way. If we want to give life to a new operating system, we must borrow every component that we can. After we have any distribution of SimpleJOS up and running, we can refine it. -- GilbertHerschberger (12 July 1999).

XFree86 is distributed under it´s own license. They consider GPL too restrictive.

--MarkAMeyer - July 13, 1999, 22:42:05 UTC

Content of these pages are owned and copyrighted by the poster.
Hosted by: