Richard Davies

Introduction

Hi there. I just happened to stumble across the JOS project last week, a day after I was again telling my flat mate how someone should really get their act together and design a system shell in Java. I have thought for a long time that Java is less like what most people describe it: [language + API] and more like [Operating System - a shell and a few other bits] and it made perfect sense to me that someone should do something with it to expand it into a full blow OS. I had already designed a brief outline of what functionality I would like to include in a Java based OS before I came across the JOS project and I thought it may be of interest so I have put it here.

About Me

Before I say any more, here is a bit about myself.
I have a B.Sc. in Computer Science, I started honours (my project was "Prototype implementation of a functional and logic programming language") but dropped out. At uni I worked mostly with various breeds UNIX. I have worked with networks and PCs for the last 5 years. I have mostly done training, support and programming. I have worked lots with MS Office. While I am far too familiar with MS Access and have a reasonable amount of skill with Oracle and SQL server. However, databases don't really interest me much any more. This year I've done my MCSE and SCJP JDK 1.1 (and soon MCSD if I can pull my finger out). I have tinkered with Java doing a few projects of my own in it (in Genetic Programming). What really interests me in computing (aside from Genetic Programming/Artificial Life/that sort of stuff) is designing systems in general.
My email address is RichardDavies@racv.com.au

My Original Ideas

I have browsed through the mailing list archives and subscribed myself to a few of the mailing lists. There are lots of interesting ideas. What I've got here are the ideas for a Java OS that I had largely prior to discovering the JOS project. I have not really had time to catch up on all the discussion so some of my ideas may have already been bandied about, enhanced or discarded. But what the hell, here they are anyway:

Goals

Before I stumbled upon the JOS project (while idly browsing the Java Lobby), my goals for a Java based OS were:

Can be installed over any OS which supports a JRE.

Will permit the the native applications and any functionality of the underlying OS provided it does not conflict with the Java OS.

Will enable a gradual transition of existing native services/applications to Java based ones.

Having browsed some of the mail archives, I cannot seem to find much mention of the idea of building JOS so that it will function over any other OS. The strong feeling I get is that a minimal Kernal will be used and the JRE and other core JOS functionality built on top of that. Not that this necessarily conflicts with what my goals are, but I was wondering how much the above issues have been discussed. I someone could point me in the right direction, or bring me up to speed, I would be grateful.

Why I think the above goals are important

It seems a natural extension for Java, a platform independant programming environment to spawn a platform independent OS. However, to create an OS that ONLY runs Java applications would seem to be of limited usefulness given the scarceness of available applications as compared to any established platform. Of course, this situation would improve with time, but there is the chicken and egg problem: You need an established OS to get people to write apps for it and you need apps to establish the OS as important. Of course, Java apps and applets are being written to run on the JRE and those apps will presumably run on JOS as well. However, what will JOS give you that another OS with a JRE can't?

Well there are already a number of things discussed in the groups that I have come across that are good answers to this: and OO file system. A distributed OS. etc..

However, what CAN'T you do under JOS with it running on it's own micro-kernal?
Run MS Office.
Use it on a computer with virtually any piece of hardware attached.
Run an enterprise database management system on it.

These are huge plusses for an OS like Windows and UNIX.

So: Why not combine the advantages of established OS's as much as possible with a Java based OS, by layering it so that it can be at least partly implemented over the top of an existing OS while still permitting access to the underlying OS's functionality and applications?

Now, I have thought about this a bit and there are definitely some difficult issues that this idea raises, but I believe that it is still possible. Also, I'm not suggesting that the entire JOS architecture could/should be able to be implemented on top of an OS running a JRE, but it would be useful if certain levels of the operating system (such as the Graphical Shell) could be "broken off" and cleanly implemented over any OS.

Levels of the Model

This was my original model for a Java based OS. At the time, I was thinking more of simply implementing a Java based Graphical Shell that would be able to be cleanly implemented on any platform.
Each level roughly describes a level of functionality.

Level 1

These are the core functions for the OS. A far too simple list of these:

Basic file system access.

Device/driver configuration.

Network access.

Process management: Start/stop any Java process or native processes.

Event processing: All events should originate from this level.

These would be the "absolute minimum" range of services upon which anything could function. Some of this functionality is implemented (and exceeded) in the JRE. Some is missing e.g.. I can't configure my hardware through the JRE to the same degree as I can using the underlying OS.

Sub level A (Modification of core OS services)

Certain functionality of the OS may possibly need to be modified. This should only need to be done when the underlying OS does not present an required interface to core OS functions that are to be exposed at Level 1. I imagine doing this, with breaking the functionality of native applications on the OS would be tricky.

Sub level B (JNI)

Implement all exposed native functionality (including that exposed from Sub Level A) that is required and not already in the JRE API using JNI. E.g.. windows registry could be accessed at this level and given a Java interface. Those core OS functions that are in the JRE API already of course do not need to be implemented.

Sub level C (JNDI)

Provide a directory based abstraction for Sub level B using JNDI where appropriate. Sub level B services could be implemented as SPIs. E.g. the Windows Registry interface at Sub level B could be built as an SPI for JNDI. I thought it would be nice to have as many as possible core OS services accessible through a unified directory interface rather than as represented in Sub level B and JNDI is designed to consolidate directory services from a variety of different platforms. This level would be 100% java, but it would still be tied to functionality present in a native OS. As the number of SPIs available from other vendors increased, they could be easily slotted in here.

Sub level D (Core Java OS interface)

Create a platform independent interface to core OS functions. This would tie to (in order of preference), the JRE API, Sub level C, Sub level B. This would not necessarily be done as a complete a separate level of API services; it may simply be a definition of which classes from java.* and sub levels A and B constitute "core os functionality". All functionality from sub levels A and B would be abstracted to make it platform independent.

Level 1 Summary

All core OS functionality exposed in a uniform 100% Java API independent of any underlying OS.

Level 2

This level would contain

All exposed native functionality (native OS apps, system services, etc.) that is not in Level 1.

Java applications built on the JRE API.

Java applications that use the Level 1 interface to extend Level 1 functionality.

Java applications that use other Level 2 services.

Note: Native functionality at this level, bypasses all functionality implemented in Java at Level 1. This biggest issue with this model is this: How can native applications and OS still function properly while handing over Core OS functionality in Level 1 to Java? This seems, even with my little experience in this area, to be a very complex issue. However, complex does not necessarily mean impossible. Also, it wouldn't have to be done "all at once". Native functionality could be gradually redirected from native OS services to Level 1. An example to illustrate what I am getting at:
Windows 95 uses a hierarchical file system. Windows explorer and the File Save/Open dialog boxes are the main native interfaces to this file system. Let's say a new file system was introduce in Java in Level 2. This file system would be built entirely over Level 1 (and possibly entirely using the JRE API). Java applications could access this new file system simply by using the new java implementation, but native applications couldn't. However, parts of the native OS could be replaced: A browser for the new file system could replace Windows Explorer and the system calls that trigger the standard File Dialogs could be redirected to use the new Java Dialogs.

A couple of other comments: This level would presumably have a component (JavaBean) architecture. Native code could also be wrapped in JavaBeans. More detail on structuring of Level 2 components should be added here but I haven't really thought about it much.

Level 3

Provide a unified directory of all native and non-native services available at level 2. This directory group native and Java based apps and services based on their functionality rather that the platform they were designed for.

A simple example:
Let's say there are both native and Java screen savers implemented at level 2. This level, when asked for "screen savers" would list both as available at this level.

This level would be suited to a JNDI interface. An SPI which lists native Level 2 applications and services could be written. Likewise, and Java based services in Level 2 could be registered automatically here (using reflection). It would be necessary for this directory to be aware of the equivalence between native and Java based applications and services.

Level 4

Shell functionality. The shell would discover services (OS config, any native or java apps, etc.) from Level 3. It would then construct a basic implementation of these as a shell. While it uses the Level 3 Unified Directory to discover services, it should be tied solely to Java implemented at Level 1 or 2. See "Transition" for why.
I call this a "virtual" shell because this level would not be an actual implementation of a shell. I noticed some discussion of Graphical and non-graphical shells. I had only considered graphical shells up till now, although the non-graphical shell would also fit in here too I suppose.

Level 5

Shell customisation. A "win95 look and feel shell", and "X/Motif" look and feel shell, etc... could be implemented at this level. These would be pluggable. Same idea as pluggable look and feels as in Swing, except, the entire shell functionality would be pluggable e.g.. how applications are launched and stopped, etc...

Comments

Some of the levels overlap a bit. This model is different from others I have seen as it emphasises the ability to maintain native functionality of an underlying OS as much as possible. It is also not necessarily mutually exclusive with the requirements I have seen either.

Transition

My aim for this design was to get a framework that would produce a working system quickly. I have illustrated how this may be done with the above model using stages:

Stage 1

Pick two Operating Systems (preferable as different as possible from each other) you would like to build upon and then do the following for each level of the model:

Design and implement basic core functionality in Java.

Do nothing here yet. OS extensions can be written later.

Write the SPI for native services at level 2. Write the code to facilitate equivalencies between native and Java code.

Design the abstract GUI. Level 2 services components could be written as necessary. Check level 3 works as intended. Check any Level 2 services work on both platforms.

Implement the GUI using the look and feel of the underlying OS. Add to Level 4 as necessary (with potential flow on to adding more components to Level 2).

Stage 2

Now, by this stage, you should be able to swap the "Look and Feel"s of the GUIs between the two platforms and they should work ok. Any combination of the following can then be done:

Add higher level OS functionality in Java at Level 2.

Redirect core native functionality at level 2 to use the Java OS.

Implement on additional platforms.

Conclusion

Thanks for reading this far! There are probably many holes with this plan that have been discussed. I have done little to revise this model in the light of what I have read in the JOS newsgroups. I just hope that I have provided some useful input. The idea of implementing over existing OS's appeals to me for these fundamental reasons:

It leverages the enormous functionality of underlying OS's. The amount of effort that has gone into building an exisitng OS (even ones you may not like) cannot be underestimated. The hardware and driver support just for Windows 95 is HUGE. The number of Windows, UNIX, Mac, Netware, etc... applications is HUGE. I believe that discarding this is a waste especially as Java presents a UNIQUE opportunity to provide an OS that could integrate this underlying functionality of an OS with services and applications that are written for Java. There is not a single other OS that could even attempt to do this.

To slowly convert the underlying OS system functionality into Java. This is a sort of reverse-Microsoft strategy :). Imagine Microsoft's reaction to being able to provide a whiz bang new file system (or whatever) to all Windows (and JOS) applications - but only if you use Java!

If native OS calls could be redirected to Java based code, and given that the source for these is going to be publically available, it would greatly open up the ability of people to provide extensions to other operating systems. And not only that, a Java based extension made for one operating system would work on others...

My main concerns are:

What what I've written is too difficult (or impossible) to implement (especially about redirecting native OS calls).

The JOS group are already intent on implementing JOS from the "ground up" and do not consider implementing JOS (in whole or in part) over other OS's as plausible or important.

Still, even if this is the case, maybe some parts of the model may be useful to you. And maybe you could develop JOS from the ground up but with these issues in mind for possibly extending parts of it over (and intergrating with) existing OS's at some future date.

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