Open Java  -- Overview

July 11, 2003

 

 

 

 

Mission

 

The Open Java(tm) Project will facilitate creative software development through cooperative sharing of Java code.

 

OJ is a foundation of multimedia code components that can be plugged together to build sophisticated applications.  Java programmers of all skill levels can build on this foundation to develop advanced applications without reinventing the wheel.

 

OJ is not a library; it is a set of standards or a coding “protocol” by which code components can communicate with one another.  By coding to this standard, programmers can independently build components that can talk to other OJ compliant code.

 

Why

 

Java is a powerful and flexible programming language, but is daunting to many programmers and requires a lengthy learning process to achieve proficiency. 

 

On the web there is a wealth of Java code demonstrating a variety of useful techniques, yet very little of this code is designed to be reused.  Most demo code is not encapsulated clearly and, though it may be open source, is not truly open to further development.

 

Programmers spend much time and effort "reinventing the wheel": creating interface and foundation code that has nothing to do with the actual techniques they are exploring.  

 

Few code libraries exist for Java(tm). The libraries that do exist typically require an "all or nothing" approach: the programmer must work with a large hierarchy of classes, pulling a lot of extraneous code and complexity into their application. 

 

An open-source system of code exchange will provide an alternative to proprietary multimedia authoring tools, and can be an educational resource for new Java programmers. 


Approach

 

The Open JAVA(tm) Project creates a framework and a means by which software development collaboration can flourish.

 

The OJ project will:

 

1. Establish a "protocol" and standards for plugging Java code components together.  Establish a "building block" approach to developing code.  This standard will clearly define how reusable components will connect to one another.

 

2. Provide a foundation of code that demonstrates this protocol, and can be easily extended to develop custom components that can plug into other OJ compliant components.

 

3. Supply a diverse selection of OJ "pluggable" components ranging from 3D rendering and physics engines to animations and sound. Developers can contribute to this selection and draw from it. These components can be plugged into other OJ components to build applications.

 

4. Provide a website through which Java programmers can publish their code components and download other programmer’s components.

 

The code foundation must:

 

  • Emphasize code exchange, not code library.  OJ is not a library, it is a means for connecting libraries.  Using OJ, independent programmers can publish components that can be plugged into any code that is OJ compliant.  They do not need to merge their classes into one library in order for this to work.   The “kernel” containing the core classes of OJ is a lightweight jar file that can be easily included in larger applications.

 

  • Encapsulate common application components such as applets, windows, frames, applications, screen controls, images, etc.

 

  • Provide environment independence (web vs. CD).   OJ compliant apps can run as Applet or App (on web or local OS).  Parameters are passed in an environment independent manner.

 

  • Distinquish generic areas of application code from specific application logic.  Provide a clear, simple, lightweight foundation of classes that delineate generic application structures.

  • Provide a useful foundation of interface, keyboard input, mouse listening, graphics, and image processing tools, so that beginners as well as seasoned programmers can rapidly gain value from the platform.  Provide additional components to demonstrate the variety and usefulness of the foundation: classes to draw curves, bitmaps to handle translucency in Java 1.1, image filters, sprite animation, physics simulation, particle engine, 3D rendering interfaces.

 

  • Use simple, clear, well commented code with shallow inheritance trees.

 

  • Use a granular structure.  Minimal exposure between classes allows features to be separated from one another easily ie. a physics engine can be reused without requiring 3D renderer.

 

  • Simple deployment.  Include one jar file in classpath.

 

 

Approach to code reusability:

 

Application code can be divided into several categories.  The application code must connect to the environment of the computer, by interfacing with:

 

            Mouse input

            Keyboard input

            Screen output

            File/Stream IO (Sockets, files)

            Context and Parameter passing (Applet vs. Application)

            Interface controls

            Sound

            Serial cards and specialized hardware boards (is this another File/stream?)

            CPU: threads and timing (system clock)

           

In addition, many multimedia apps will interface with libraries for:

            Geometry (2D and 3D shapes, transform, scale, move points in space)

            Image processing

            Physics

            Rendering (2D and 3D image generation)

 

When a class combines two or more of these areas, it becomes difficult to reuse.  For code to be reusable it should perform one function and not two, ie. classes that generate geometry should not also render that geometry..  Classes that Render should not also generate geometry.  Classes for multimedia display should not refer to specific parameter passing conventions, or assume they are running in a web context (nearly all apps online assume they are running as an applet).