Lo scopo di questo progetto è di produrre un software che sia allo stesso tempo:

Una macchina virtuale Java condivisa
Permette di lanciare differenti programmi nella stessa VM. La VM sarà sempre attiva, quindi riduzione dei tempi di partenza dei programmi e minore consumo di RAM.
Utilizza JDSVM(Java Desktop Shared Virtual Machine), che a sua volta si basa sull'ottimo Progetto Echidna di Javagroup.

Un server locale Xml Rpc
In questo modo è possibile accedere ai servizi esposti dal motore anche per programmi scritti in linguaggi diversi da Java.

Motore estensibile
E' stato sviluppato con una architettura estensibile, così che sia possibile creare nuovi "servizi" per il motore.

Servizio Linux/Windows (prossima versione)
Verrà lanciato come servizio in maniera trasparente, sempre accessibile per gli altri programmi.

Per dettagli vedi le sezioni Introduzione e Manuale .

Scarica

E' disponibile la versione 1.0 di "Java Desktop Engine". Premi qui (800KB) per scaricare.
Il codice sorgente per questa versione non è ancora disponibile.
Per scaricare la versione 0.8 di "Java Desktop Engine" premi qui (940KB).
E' disponibile anche il codice sorgente. Premi qui (820KB) per scaricare.

Introduzione

Per quelli di noi che fanno uso di strumenti Java è frustrante dover aprire diverse VM ingorde di risorse solo per lanciare utili ma semplici programmi. Per di più, il tempo di avvio di ogni VM è tempo sprecato. Abbiamo tutti apprezzato la differenza quando si compila all'interno di un IDE. In questo caso (opzione in genere selezionabile nelle opzioni dell'IDE), javac viene lanciato come processo all'interno di una VM già attiva, e la differenza di velocità è evidente.

JDE è nato per cercare di almeno alleviare questo problema.Avere una VM sempre attiva all'interno della quale sia possibile lanciare processi(leggi programmi), significa maggior velocità di partenza dei processi e minure utilizzo di risorse. Si rsparmia molto tempo, evitando di caricare continuamente una nuova VM.
Non c'e niente in nuovo in tutto ciò. Alcuni ottimi progetti al riguardo sono attivi sulla rete, alcuni orientati a produrre interi ambienti grafici Java, altri semplici VM condivise. JDE si posiziona in parte vicino a queste ultime, ma è più un motore esetnsibile che espone servizi(la VM condivisa è solo uno di essi).
Esistono diversi approcci per implementare una VM condivisa, ognuno con i suoi punti di forza e difetti. Abbiamo scielto di utilizzare l'ottimo codice del progetto Echidna Project per il momento. Documentazione più tecnica al riguardo è prevista...

"Non omne quod nitet aurum est"

Veniamo alle brutte notizie:
1) Proprietà/Ogetti di sistema statici.
System.in, System.out,System.err sono condivisi all'interna di una singola VM. Si, potremmo definirne diversi per singoli processi, ma questo implicherebbe dover modificare il codice dell'applicativo lanciato come processo per renderlo "compatibile" con JDE.
2) La coda degli eventi della interfaccia grafica(GUI).
Esiste una sola coda eventi GUI per VM quindi, ad esempio, un dialogo modale attivo di qualsiasi processo caricato nella VM è modale per tutta la VM.
3) Sicurezza.
Naturalmente, quasto approccio rompe la gabbia di sicurezza della VM. Esistono differenti soluzioni al problema, ma tutte parziali. Comunque, a seconda dell'uso che si fa di JDE, questo potrebbe essere o meno un problema.
4) Un processo che vada in panico, manda in panico tutta la VM....:(
Certo, con programmi scritto bene non dovrebbe accadere,però......

Il punto di accesso di JDE è un server XML-RPC che accetta chiamate per servizi. Tutte le richieste per JDE passano da quì.
Il principale servizio esposto da JDE è ovviamente quello di lancio dei programmi. Facendo una chiamata si lancia un programma come processo all'interno della VM attiva. Avere un server XML-Rpc permette di utilizare qualsiasi linguaggio/piattaforma che abbia funzionalità di cliente xml-rpc. A titolo di esempio è incluso un semplice script in python utilizzabile per lanciare programmi (vedi lo striminzito manuale dettagli).

E' anche incluso un "Gestore", un semplice applicativo swing per la visualizzazione/lancio/chiusura di programmi all'interno della VM.
Eventualmente questo verrà aggoirnato per la gestioni di futuri servizi attivi su JDE fino ad essere una sorta di gestore completo del motore.

Sono inclusi:
1) Un "lanciatore" di programmi/processi Java. Quello da cui nasce questo progetto. Serve per lanciare programmi dentro la VM attiva.
2) Un motore di scripting. Attraverso semplici chiamate xmlrpc è possibile lanciare degli script sul motore ed ottenerne indietro i risultati. Attualmente come linguaggio di scripting è supportato BeanShell. In seguito tramite BSF(o il nuovo meccanismo di Mustang) ne saranno supportati altri.
3) Un semplice e veloce "editore" di testi Basato su jEdit Syntax Package 2.2.1, un semplice, rapido e utile editore con solo alcune delle comodità alle quali jEdit ci ha abituati.
Altri prossimamente.................

Faccio uso quotidiano di JDE e, anche se in beta, è piuttosto stabile.
Questa è un'immagine di vari programmi + il gestore di JDE lanciati in un'unica VM.
(Cliccare per vedere l'immagine ingrandita)



Solo per dare un'idea grossolana, l'intera VM (VM condivisa+ gestore + tutti i programmi) su una Mandrake Linux, kernel 2.6.0-1, J2sdk1.4.2 senza alcuna opzione speciale sulla VM occupa 46MB. Sulla stessa configurazione, gli stessi programmi lanciati in singole VM occupano più del triplo della memoria.

Cosa manca Solamente, una marea do cose. JDE al momento non si cura della sicurezza. Questo deve essere visto al più presto. Non è sicuro che le prossime versioni utilizzeranno Echidna, stiamo valutando delle alternative. Stiamo anche cercando una soluzione al problema della coda di eventi singloa della GUI, ma onestamente noon sono sicuro che sia risolvibile sulle VM attualmente disponibili. Molte estensioni/script verranno implementate; alcune sono in fase di sviluppo ora, altre verranno in seguito. Stiamo anche lavorando su esempi in altri linguaggi per lanciare i processi in JDE. JDE è stata testata solo su Linux, ma utilizza solo caratteristiche standard di Java, per cui penso che debba funzionare anche su altre piattaforme.

(non ancora un) Manuale

Un vero manuale ci sarà se il progetto riceverà interesse. Per ora consideriamo questo come un "cosa può fare questa versione". Essenzialmente, le funzioni di base sono già implementate. E' possibile lanciare processi o script nella VM, c'è un applicativo di gestione per il lancio/chiusura , alcuni script in python per fare chiamate xml-rpc al motore e alcune altre amenità.Il motore funziona e, a seconda di ciò che ci si lancia dentro, è abbastanza stabile.
Quindi, accendiamolo...

Prerequisiti

Una J2DK >= 1.4.0 dovrebbe essere tutto ciò che serve....

La prossima versione avrà un installatore, spero... Comunque, anche ora non è difficile. E' sufficiente decomprimere il file scaricato. Verrà creata una struttura di directory. Ecco una breve spiegazione di cosa ci troverete:

Directories

• - lib contenente i jars delle librerie/estensioni caricate all'avvio dal motore
  
• - scripts contenente gli script(al momento solo script BeanShell) automaticamente visibili al motore(vedi dopo..)
  
• - conf configurazioni e regole di sicurezza
  

Files

• - startup.sh Da lanciare (su Linux) per far partire il motore(in futuro il motore sarà un servizio Linux)
  
• - jva/jde script python per usare il motore(vedi di seguito..)
  
  

Basta lanciare run.sh . L'eseguibile "java" deve essere nel classpath. Non molto elegante, lo so... Al momento sono utilizzabili 2 parametri al lancio:
1) GUIManager ,lancerà anche l'applicativo grafico di gestione.
2) -LnF <look'n feel> ,dove <look'n feel> è la classe principale dell'implementazione di look'n feel, e dando per scontato che il corrispondente jar sia in lib.
es. immaginando di usare Liquid LnF (uno dei miei preferiti), bisognerà mettere LiquidLnF.jar in $JDE_HOME/lib e lanciare JDE in questo modo : startup.sh -LnF com.birosoft.liquid.LiquidLookAndFeel
n.b: Se verrà lanciato un processo dentro JDE che imposti un altro LnF, i successivi processi lanciati erediteranno l'ultimo LnF impostato. Suppongo che il LnF sia globale per la VM...

Usarlo

Bene, lanciato il motore, e ora?
Si possono lanciare processi dentro il motore usando il gestore grafico(prossimo capitolo), o facendo semplici chiamate xml-rpc al motore. In $JDE_HOME, c'è uno script python, "jva", che serve proprio a questo. Bisogna lanciarlo così:
jva <classpath> <classe.principale> <parametri del programma>
es.: per lanciare la classe "org.my.class" che si trova nel jar /home/my/myclass.jar :
jva /home/my/myclass.jar org.my.class , simile a "java" ma senza flag. Attenzione ad usare sempre percorsi assoluti. Lo script è in versione preliminare.
Un altro script utile è "jde"(stessa directory di jva). E' destinato a diventare uno script completo di gestione. Per il momento gestisce gli script(quelli in beanshell). Lo si può lanciare con 2 diversi parametri:

• getScriptList restituirà la lista di script installati in $JDE_HOME/script
• launchScript <nomescript> lancerà lo script "nomescript".
  I.E. : lanciando "jde getScriptList", nella lista di script ci sarà "Editor.bsh". Per lanciare quest'ultimo basta digitare "jde launchScript Editor.sh". Tutto quì.

"jde" e "jva" sono solo esempi di quanto sia facile interagire col motore usando linguaggi diversi da Java.
Teoricamente qualsiasi linguaggio con supporto xml-rpc è in grado di interagire con JDE.

Si può lanciare in 2 modi:

• Lanciando JDE col parametro "--GUIManager"
• "jda ./ org.beanizer.jdsvm.manager.ManagerSwing" (il parametro di percorso
  non è in questo caso importante perchè le classi usate sono già caricate).

La sezione "1" della finestra permette di lanciare processi, proprio come lo script "jda". La sezione "2" mantiene una lista di processi attivi e permette di chiuderli. Basta selezionare un processo e premere "Kill". La lista si aggiorna automaticamente quando un processo venga aperto/chiuso. "Refresh" aggiorna la lista. La voce di menu "History" mantiene una lista di nomi di processi lanciati. Per processi lanciati più di una volta mantiene solo una referenza. E' utile per lanciare più volte uno stesso processo. Versioni future del Gestore includeranno installazione/disinstallazione di estensioni/script, statistiche sul motore e una caterva di altre cose totalmente inutili ma forse carine:)

• Una marea di debugging
• Valutazioni di altri modelli multi-processo
• Un installatore, auto aggiornamento e contenitore di plugin online(a la jEdit)
• Nuove e (speriamo) utili estensioni (idee/suggerimenti sono sempre ben accetti)