Re: [JOS-Kernel] Building Java operating systems

[Gilbert Carl Herschberger II]

Thank you, John Leuner! <[EMAIL PROTECTED]>

>My experiments so far have allowed me to run simple java apps on this
>kernel (the kernel is about 700k). You need to provide the class libraries
>too, so one option is to include these in the boot image, but this posed a
>problem with size (the libraries are several megabytes). It takes too long
>to boot the kernel, so I wrote a very simple HTTP loader that just asks my
>linux machine running apache for the class files.

Using the classic model of very large archives, it takes far too long to
start a virtual machine. If you had to statically link the 20+MB rt.jar to
the kernel/virtual machine, you would never boot.

Just like you, I wrote a simple HTTP-based class loader. It downloads
classes from my Linux machine running Apache, too.

This has been bothering me for a year and a half. I have been puzzling over
this part of the architecture far more than any other issue. Right now, I
might be using part of the solution.  For my intranet applications,
customers use my Cooperating Runtime Environment (CRE). cre is a tiny 60KB
program that uses the Invocation API from JNI to start a JRE and launch any
Java application off the network through an HTTP service. The path to an
HTTP service is optional and configurable. The shell, or first class
invoked, is optional and configurable. When you don't specify a shell, cre
launches the Universal Browser.

Here is the break through that makes the CRE possible.

I do not store bytecode in .class files. While downloading from HTTP, that
would consume far too many network resources. Each file requires its own
connect-download-disconnect cycle.

Neither do I store bytecode in .cab, .jar, or .zip files. Downloading a
20+MB rt.jar from HTTP is just about as bad as having a 20+MB boot image.

What do I do?

I store bytecode in package files. My HTTP-based class loader downloads one
package at a time, which matches the semantics of Java bytecode exactly.
All package files have a .jpkg extension. For each of the HTTP servers
where package files are stored, all package files are found in the /jpkg
directory.

Package files are given a rigorous naming convension so that you can build
packages files with the greatest of ease and the package-based class loader
can find package files directly. The name of a package is the name of the
package file, plus the .jpkg extension. Here are some examples, off the top
of my head:

java.applet     java.applet.jpkg
java.awt     java.awt.jpkg
java.sql     java.sql.jpkg
java.util.jar     java.util.jar
java.util.zip     java.util.zip.jpkg

org.jos.console3a     org.jos.console3a.jpkg
org.jos.smartapi2a     org.jos.smartapi2a.jpkg

>Then what I do is make a barebones zip file containing the most commonly used
>class files (for running a helloworld program for example) which comes to
>150k and put this in the boot image.

Packages must be download *as needed*, rather than all at once. JDBC,
JFC/Swing, JSDK, and many parts of the 20+MB rt.jar are not part of the
core, or linked to the kernel/virtual machine, because there are many
applications that will never use them. Only these packages are truely core:

java.io
java.lang
java.net
java.util
org.jos.gchii.packageloader1a

Your "barebones" zip is just like my true core zip. It contains only those
classes that are absolutely necessary to get to a point where additional
packages can be downloaded. It is part of a bootstrap startup sequence.

Your experience with the OSKit and Classpath project would surely help the
JOS Project finish its Java-based operating system.


_______________________________________________
Kernel maillist  -  [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel