| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
Currently, it seems as though JOS will be using (or modeling after) JavaOS for Business's API.
See also [ PlatformAPIDiscussion ]
-- MattAlbrecht - 16 Nov 1999
Upon further thought, this topic needs to be flushed out. The current JOS model is divided into a hierarchy as so:
Where does the PlatformAPI fit in? According to the JOSystem page, JOSystem only pertains to making the "glue" to tie the basic Java resources required by a JDK with the JOSBox, allowing Java programs to run in a stand-alone environment without an underlying OS.
The JOSBox is highly undefined. It is assumed that the KernelGroup is directly in charge of the JOSBox, as the underlying Kernel and JVM are together in the JOSBox, which are written in minimal C or C++ (or assembly).
The PlatformAPI is below the driver layer (wherever that is), yet above the Kernel. It acts as a gateway between the basic hardware resources and the drivers which use them.
So, if we are so inclined, we can dissect the JOSBox layer into:
See also [ KernelGroup ]
-- MattAlbrecht - 17 Nov 1999
Is there a mechanism in decaf for native methods? I understand that it does not look like the JavaNativeInterface. In a typical native call from JOSCore, bytecode asks the JVM to request something of the JOSBox.
JOSBox might be compiled into a JOS kernel and used by the JVM.
There might be more than one implementation of the JOS kernel since a slightly different implementation is required to run on different processors and hardware.
The platform API might be a common set of subroutines (methods) available to the JVM to use the JOSBox.
Surely decaf makes calls to JJOS. Any JVM will need an interface to the kernel.
How does the KernelInterface fit in? The JVM needs the kernel to do stuff. -- GilbertHerschberger (17 November 1999)
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|