Overview

About this document

This document provides a summary of the CjOS Project @ cjos.sourceforge.net.

Content

This document contains the following sections:

• Section A - Our Project
• Section B - Our Results

Section A - Our Project

Introduction

This section highlights some of the features of our project.

Goal

Maintaining an object-oriented class library in any programming language presents certain un-avoidable challenges. Maintaining a Java class library is no exception. Typically, dependencies among class libraries are more complex than dependencies of equivalent function libraries.

We ask, " Is perfect backward compatibility possible? " Our research shows that perfect backward compatibility is both possible and beneficial. Certain design patterns emerge. Specific programming techniques are recommended.

Our project provides use-able, re-usable, production-quality components. Further, it demonstrates how we have put these design patterns and programming techniques into practice.

Open source

Our project is open source software so that you can review what we have written and, hopefully, learn from it.

Free license

Our project is free license software so that you can include our production-quality components in your software.

Relationship with sourceforge.net

We are grateful to sourceforge.net for their continued support of open source and free license software. sourceforge.net enables us to concentrate more on the development of high quality Java software and less on infrastructure, such as a website, CVS repository and file release system.

Relationship with JOS Project

We thank members of the JOS Project for their contribution to our success. The JOS Project @ sourceforge.net enables us to concentrate more on building the Java software and less on providing a development infrastructure. We share the JOS Wiki with other sister projects. We share the jos-general mailing list.

Section B - Our Results

The Java community has not yet embraced the need for stability. Stability is the presumption that an API is backward compatible, unchanged, unchange-able. It is a prerequisite for building an operating system.

C

The C programming language embraces a separation of concerns. The API for an application as large as a kernel is distributed as header files. The most senior programmers are given the responsibility of maintaining header files in a backward compatible way. The header files are a most important asset; it defines the interface to a kernel.

C++

Like C, the C++ programming language embraces a separation of concerns. The API is distributed as header files.

• Generalization: The header files in C++ are more difficult to maintain in a backward compatible way.

Compared with C++

Like C++, Java technology from Sun Microsystems strongly support object-oriented programming.

Unlike C and C++, Java technology does not embrace a separation of concerns. Both an API and implementation are compiled into class files.

• Both are often distributed in the same jar.

Like C++, Java technology supports a standard class library.

Unlike C++, the standard Java class library does not embrace a separation of concerns. Both API and implementation are distributed in the same jar.

Unlike C++, the standard Java class library does not embrace backward compatibility and stability required by an operating system.

Operating system

An operating system is a critical, vital piece of software. Likely, the kernel is the most important piece of software running on a machine.

Impossible?

Without a preprocessor and many versions of Java, it is difficult to build a Java-based operating system. The following versions of the standard Java class library exist:

• JAVA 0 (JDK 1.07)
• JAVA 1 (JDK 1.1.7b)
• JAVA 2 (JDK 1.2.2)
• JAVA 3 (JDK 1.3.0)
• JAVA 4 (JDK 1.4.2_10)
• JAVA 5 (JDK 5.0)
• JAVA 6 (JDK 6.0)

But, it is not impossible.

Explicit versioning

In order to increase stability to the level required by an operating system, use explicit versioning.

Explicit versioning requires each version of an API to be written into a separate package. There is more than one proposal for package naming.

Let's take Smart Api as an example.

• Version 1a - org.jos.smartapi1a
• Version 1b - org.jos.smartapi1b
• Version 2a - org.jos.smartapi2a
• Version 3a - org.jos.smartapi3a
• Version 4a - org.jos.smartapi4a
• Version 5a - org.jos.smartapi5a

Version 1a of the Smart API is still available today, exactly as it was published. Any program that depends upon version 1a continue to run--without modification.

Universal factory

A universal factory enables a program to run--without modification--on a number of different versions of Java, on a number of different test systems.

Some examples of a universal factory include:

• Bytecode Native Interface (BCNI)
• Smart Api

How do we maintain a very large class library?

The strongest bonds are bonds of cohesion and dependency. Therefore, a very large class library should be divided along lines of cohesion and dependency. To reduce the number of dependencies, it is important to develop well-known interfaces and base classes. A well-known interface survives the test of time. It remains the same for a life-time.

1. Premise: A very large class library must be built from its source code.
   1. Consequence: It is not pragmatic to distribute a very large class library as one giant archive.

   2. Consequence: It is not pragmatic to build a very large class library as one giant archive.

   3. Consequence: It is not pragmatic to allow each class depend upon all other classes.

2. Premise: Building from source code must be repeat-able.
   1. Consequence: An artifact must be re-built when its dependent artifacts have been re-built.

   2. Consequence: An artifact must be re-tested when it is re-built.

   3. Consequence: It is not pragmatic to build all artifacts when only one artifact has changed.

3. Premise: Artifacts must be distributed.
   1. Consequence: The maintenance process itself is distributed.

   2. Consequence: Artifacts must be installed on a production machine.

4. Premise: Artifacts must be customize-able for multiple versions of Java.

5. Premise: Artifacts must be customize-able for multiple operating systems, such as
   • Linux,
   • OS/400, and
   • Microsoft Windows.

6. Premise: Artifacts must be customize-able for multiple containers, such as
   • Apache Ant,
   • Java application,
   • Java applet,
   • Java servlet,
   • JSP,
   • EJB, and
   • Web service.

By experimenting with a number of different strategies, we have identified strategies that work and strategies that do not work. What strategy are you using?

1. A uniform resource identifier (URI) provides access to a mechanism.

2. A mechanism is implemented behind a well-known interface and corresponding factory.

3. A plug-in is developed to connect the URI mechanism with the corresponding factory.

4. An implementation is maintained with XML Varient Configuration Language (XVCL). XVCL enables a very large class library to remain flexible and nimble.

Benefits

1. Repackaging after the fact. Assigning a part to a model is external to the part.

2. Experimental code co-exists with production code.

Concerns

1. Dividing a very large class library into relevant, independent modules requires much skill.
   • A class can be developed in multiple modules.
   • Namespace must be managed across multiple modules.

2. Any division of a very large class library adds complexity to the production environment because multiple inter-related artifacts must be installed, not just one.

3. Any division of a very large class library adds complexity to the development environment because it is possible to develop a class in multiple modules.

4. Adding XVCL to Java development environment demands additional skills.
   • XML
   • Apache Ant
   • Installing XVCL Plug-in for Eclipse 3.1.

Theory vs. Practice

Software development is a practice. How do we experiment with different strategies? We select a strategy and use it to develop a very large class library. By practicing a strategy we learn about the consequences, predicted and unpredicted.

• Apache Ant. Rebuild a module from its original source code. The build process is distribute-able; it can be distributed to other developers.
• BulkMake. Develop and use incomplete implementations of a package.
• WebSource. Review the source code, even incomplete implementations.
• JavaDoc. Comprehend a module of a very large class library.
• CVS. Support platform-independent modules compatible with multiple operating systems, such as Linux and Microsoft Windows.
• XVCL. Generate the Java source code, package.html, properties files, Ant scripts, and other resources.
• Smart API. Select platform-dependent modules at runtime. Select implementation at runtime.