Translations available:

Proposed Harmony Architecture

This is based on "Harmony: The Apache J2SDK Project" ( with a few changes taken from the Harmony mailing list ( Please direct any comments and discussions there, and include changes on this page when consensus is reached.

Harmony is a project from the Apache Foundation aimed at creating a stable and open-source implementation of the Java 2 SDK. It is not a Java 2 Enterprise Edition (J2EE) application server, nor does it handle the Java 2 Micro Edition (J2ME) applications.

Initial Requirements

The major requirements for Project Harmony are evident and given by the JDK Technology Compatibility Kit (TCK). Several other requirements are, however, required:

  1. Simple porting and use of OS native facilities. This requirement can be managed by introducing the OS Abstraction Layer (OAL) which is the only point of contact between the JVM and the native OS, or the tool library and the native OS respectively. It is vital that the OAL is thin and that its boundaries may be moved within the JVM to deliver optimum performance on all or most OSes.
  2. Reduce required library clutter and promote augmentation of JDK tools. This requirement can be met by using a common library for all tools. By reducing the number of top-layer dependencies and keeping a clean API, we may increase developer throughput in project aiming to provide, say, GUI versions of JDK standard tools.

Please provide more suggestions for requirements - and let us keep them measurable from now on. :)

Initial Architecture and Subprojects

I propose initial architecture and subprojects for Harmony as outlined below. Each of the (sub)projects should adhere to the standard Apache project model, unless a particularly good reason tells us not to. Originating from the early discussions on the Harmony mailing list, I have created some structure sketches on the project.

The main internal structure of the JVM and class library project is illustrated above. According to discussions on the development list:

JVM subprojects

The main Harmony project in terms of volume is likely the JVM project as illustrated in the overall project structure above. We should therefore split the development effort of the JVM project into a few subprojects. as illustrated below.

It seems reasonable that we can identify (at least) three subprojects with a number of development goals inside the JVM. These are

As usual, these may not be the optimal or final project or development streams. Your comments are welcome.

Development Facilities Subprojects

Development facilities exist to enhance the overall development process, and should be stripped from the build in production releases (or, at least, non-development and -debug releases). Development facilities may explore state or data flow in any layer of the JVM, class library or OAL.

I recommend (at least) the following projects under the Development Facilities umbrella.

Again, feedback is welcome - but use the Harmony mailing list for the feedback.

Modular Structure JVM Components

The diagram below is is a standard UML component diagram: each component is represented as a box and exposed interface groups are shown as annotated "lollipops." The annotation identifies the corresponding interface group. Colors represent functional areas associated with components, interface groups and dependencies.

Modular Virtual Machine Interfaces Component Diagram ModularJVM.jpg

VM Core Sub-components

J2SDK Toolkit Architecture

In addition to the JVM and classpath, the standard JDK tools must be implemented for Harmony. These tools includes:

These utilities can either be written in Java using the classpath project, or written in C/C++. In the later case we should, to promote reuse and facilitate deployment, strive for a single distribution library (called Common Tools Library or CTL in the image below) on top of the OAL from the JVM project.

The overall tool goal is to permit or promote augmented clients in addition to the standard-named ones. I believe most of us would like to see an augmented keytool that could - say - provide native OpenSSL CA management directly to the default keystore. Given a decent Swing-based GUI for the job, key management annoyances would likely be greatly reduced compared to today's text-based equivalent. Alas, we would strive for the situation illustrated below:

HarmonyArchitecture (last edited 2009-09-20 21:54:24 by localhost)