| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
org.jos.core.*...For current progress, see JOSCoreProjectUpdate
This project is part of the ProcessGroup, a subgroup of the KernelGroup. Since the MailingLists reorg has taken place, the proper mail list to discuss JOSCore issues is arch@jos.org
JOSCore (aka org.jos.core.*) will be used to implement the Java API's. - AveryRegier [1]
In other words, java. packages depend on classes inside org.jos.core.. Private and default methods are not part of a specification for the Java class libraries. Such private methods are JVM-specific and require corresponding shared (or dynamic link) libraries. Only the public and protected methods of java.* packages must be preserved when reimplemented for a JVM, like decaf.
Here is the architecture diagram from the bottom up.
| Non-JOS | JOS |
| native OS | JOS kernel |
| Java virtual machine | Java virtual machine |
netscape.* packages sun.* packages |
org.jos.core.*
|
java.* packages
|
java.* packages
|
| Java applications | |
Using class libraries below the java. packages is not a new idea. This is something like netscape. packages in the Navigator. and other sun.* packages in Sun Microsystems's JDKs.
The java.io.File class, for example, uses a private native method to list files in a directory. A JOS-specific implementation of java.io.File might not use a native method at all. Instead the java.io.File class uses a class from org.jos.core.* to list "files" in a "directory".
There must be more than one Java API. The native methods API is an API between Java class libraries and the Java virtual machine. The native methods API for Java 1 and 2 platforms is based upon the mechanism of JavaNativeInterface (JNI). The native methods API is the specific list of native methods used by the java.* packages.
And then, there is the Java class libraries. The Java platform API is an API between java. packages and all other packages. Your application packages are supposed to be built upon the java. packages -- GilbertHerschberger (17 November 1999).
...by JOSCore I mean the minimum Components for JOS to run on the JOSBox and still be considered an OS... - DigiGod [2]
The JOSCore is the minimum number of classes required to implement the java.* packages. The word core itself brings to mind all of the packages that are required in order for the product to run at all. If a package is not immediately required, it is optional and not part of the core.
The JOSCore must be kept to a minimum. With the new kind of general purpose processor, some of the things we might have taken for granted in an operating system becomes optional. A local window manager, for example, is optional on a machine that has no video hardware. A local OS file subsystem is another example of an option on a general purpose processor with no storage hardware.
Bad things happen when everything is put into the core. For more information about one extreme, see also EverythingIsCore. -- GilbertHerschberger (17 November 1999).
Attention: Please do not confuse JOSCore with org.jos.core., as I have. While JOSCore is a distribution issue, org.jos.core. is a collection of Java packages, implemented in bytecode.
The minimum and maximum implementations of this platform are distribution issues. JOSCore alone is a minimum installation. JOSCore plus every JOS-compatible extension every written would be a maximum implementation.
How is JOS installed?
There is nothing optional inside JOSCore. You are required to install everything inside JOSCore. JOSCore is the minimum requirements of a JOS platform. When JOS is distributed, there are a minimum of components that are absolutely, positively required in order for the operating system to be called JOS. The minimum requirements are an issue of distribution. The minimum requirements of JOS is called JOSCore. The minimum requirements will be defined and refined as part of the JOSCore project.
Recently, we have discovered that org.jos.core. packages are optional. When a virtual machine implements the BytecodeNativeInterface (or BCNI), it is possible to skip org.jos.core. classes and go directly to JVMSpecificClasses. Using a technique of pseudo-native methods, methods with a native attribute can be written in bytecode. When bytecode invokes a method with a native attribute, it is intercepted by a virtual machine and a JVM-specific method is invoked instead. -- GilbertHerschberger (6 December 1999).
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|