Architettura proposta di Harmony

Basato su "Harmony: Il progetto J2SDK di Apache" (http://www.jguru.se/jguru/control/Developers/Harmony) Con alcune modifiche prese dalla Harmony mailing list (http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev). Siete pregati di inviare ogni commento e discussione là, e di includere le modifiche quando si raggiunge il consenso.

Harmony è un progetto della Apache Fundation mirato a creare una implementazione stabile ed opensource del Java 2 SDK. Non è un application server Java 2 Enterprise Edition (J2EE), nè gestisce aplicazioni Java 2 Micro Edition (J2ME).

Requisiti Iniziali

I principali requisiti del Progetto Harmony sono evidenti e sono dati dal JDK Technology Compatibility Kit (TCK). Vi sono pero diversi altri requisiti:

  1. Semplicità di utilizzo e porting dei servizi nativi dell'OS. Questo requisito può essere gestito introducendo un OS Abstraction Layer (OAL) che è l'unico punto di contatto tra la JVM ed l'OS nativo, o le tool library e l'OS nativo rispettivamente. E' vitale che l'OAL sia snello e che i suoi confini possano essere spostati all'interno della JVM per portare performance ottimali sul maggior numero possibile di OS.
  2. Ridurre la confusione nelle librerie richieste e promuovere un'aumento dei tool del JDK. Questo requisito può essere soddisfatto usando una libreria comune per tutti i tools. Riducendo il numero delle dipendenze top-layer e mantenendo un'API pulita, possiamo aumentare il troughput degli sviluppatori nel progetto puntando a fornire, diciamo, versioni GUI dei tools standard del JDK.

Siete pregati di fornire ulteriori suggerimenti per i requisiti - e consentiteci di mantenerli misurabili da ora in poi. :)

Architettura Iniziali e Sottoprogetti

Propongo un'architettura iniziale ed alcuni sottoprogetti per Harmony delineato di seguito. Ogniuno dei (sotto)progetti dovrebbe aderire al modello di progetto standard di Apache, a meno che una particolare ottima ragione non ci suggerisca di fare altirmenti. Prendendo spunto dalle discussioni iniziali sulla mailing list di Harmony, ho creato alcune bozze della struttura del progetto.

http://www.jguru.se/jguru/Channel_Html/generic/images/developers/harmony/overall.jpg

La principale struttura interna del progetto della JVM e della class library è illustrato di seguito. Secondo le discussioni sulla lista di sviluppo:

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. http://www.jguru.se/jguru/Channel_Html/generic/images/developers/harmony/jvm_projects.jpg

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.

http://www.jguru.se/jguru/Channel_Html/generic/images/developers/harmony/devfacilities_projects.jpg

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.

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.

http://www.jguru.se/jguru/Channel_Html/generic/images/developers/harmony/tools.jpg

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:

http://www.jguru.se/jguru/Channel_Html/generic/images/developers/harmony/tools_example.jpg

HarmonyArchitectureItalian (last edited 2009-09-20 21:54:55 by localhost)