JosAPI.Imported @ jos.sf.net

Every OS has an API - so has JOS. (API here means the system classes that are exposed to applications.) The difference with JOS is that the main part of its API will be the standard JDK API - the java.* classes.

The JDK API is not everything, though. There are many areas where an additional JOS API will be needed; primarily for system maintenance utilities - which is one reason to keep the JOS API as small as possible. Another reason is that we want to encourage the development of Pure Java apps, not "Pure JOS apps."

I've talked long enough, here it is, the list:

A related page [we still have to figure out what the relation is]: JosServices

Package Pure Java? Maintainer Target applications

java

No YourNameHere All

javax No YourNameHere All

javax No YourNameHere JOS Kernel, VM Support, Drivers, and System Routines.

org.jos Yes YourNameHere JOS Operating System.

org.jos.api Yes, Interfaces Only StefanReich / ClarkEvans JOS Application Program Interfaces - see StefansAPIStructureProposal

org.jos.Registry Yes StefanReich / ClarkEvans The Registry Object knows which org.jos.api.* interfaces are available and implemented in the system

--As always in this WikiWorld, anyone may edit anything on this page.

I'm confused; does this page only contain focused JOS services, like basic system tools, or does it include fancy system service layers like link services, inter-app messaging, etc. that work above the 100% pure java JDK core?

--BradNeuberg, 3/25/98

The 100% pure services should be placed in org.jos.lib (the 100% pure part of the JOS API). Does that help?

--StefanReich, 26-Mar-98

I modified the table above. Basically, I see a regisry object and an api package. The services are defined in org.jos.api by 100% Pure Interfaces. If an application (or any system service recursively) needs a service, it asks the registry for an object that implements the service. If the service is available on that computer, then an instantiated object is returned, otherwise a org.jos.api.SERVICE_NOT_AVAILABLE error would be raised. This way it does not matter if the service is implememented in the org.jos.* 100% Pure Stuff or the jos.* Native. Applications which have to run on any VM should not use org.jos.Registry object unless they have written the code to handle the case where the service is not available. The registry object could also have a method which allows a program to ask "Are the X, Y, Z services available on this computer?" when the program starts. This way the un-availabilty of the nessary services can be handled intelligently. Anyway, this is what I remember we decided along time ago... but I could be mistaken. - ClarkEvans

Very good, Clark! I agree with everything. --StefanReich, 27-Mar-98

I wrote a org.jos.api.APIRegistry implementation. What do you think about it? --StefanReich, 27-Mar-98

Cool. Although api.API was redundant. -- ClarkEvans 28-Mar-98

APIStructure. -- RobertFitzsimons (31 March 1998)

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