Newsgroup: it.comp.java
Titolo: Reportage dal JavaOne, Day 2

Se interessa, sto scrivendo un reportage dal J1, day by day. La prima
puntata e' su 
www.programmazione.it
, la seconda dovrebbe esserlo a breve,
nel frattempo la posto qui per comodita'.
ciao
uL
------------
Buongiorno da San Francisco, day 2! (veramente e' il day 3, ma scrivo con
un giorno
di ritardo :) )
Nota personale: ho assorbito finalmente il fuso orario... cosi' forse
potro' raccontarvi
anche quello che mi sono scordato del primo giorno.
Giornata intensa la seconda del JavaOne, iniziamo con qualche numero.
Sembra che l'affluenza
sia molto buona, in crescita rispetto alle ultime due edizioni anche se
non ancora
ai livelli di... fine secolo. Qui si parla di oltre 15000 persone, vedremo
poi i dati
ufficiali a fine conferenza.
Il keynote di Scott McNealy e' stato molto piu' breve, come consuetudine,
di quello
del primo giorno. Scott e' stato pungente come suo solito, non sono
mancate le battute
acide per gli analisti e anche qualcosina per le famose "open letter"
sull'apertura
di Java all'open source. Un divertente cartone animato con  protagonisti
lui stesso
e Steve Ballmer, CEO di Microsoft, ha raccontato in maniera spiritosa
l'accordo con
l'ex nemico numero 1.
James Gosling ci ha come al solito bombardato con le sue magliette
"speciali", e come
al solito non ne ho presa nemmeno una. Questa volta ha usato un cannone
attivato dall'energia
di due... ciclisti.
Vi garantisco che qui l'atmosfera e' elettrica e sia gli annunci che le
nuove tecnologie
si susseguono a ritmo incalzante. Proprio per questo qualche volta ci si
ritrova a
non riuscire a valutare correttamente l'impatto di una notizia.
Passiamo in rassegna - in ordine pseudocasuale - le news tecniche a mio
modo di vedere
piu' interessanti e che avranno piu' impatto sulla vita quotidiana degli
sviluppatori.
Ovviamente J1 e' cosi' grande che non si puo' assistere a tutto, quindi mi
riservo
il diritto di aggiungere dettagli a questa lista in ogni momento :)
- J2EE. Gli EJB, per come li conosciamo, non esisteranno piu'. Si, avete
capito bene.
EJB 3.0 e' un passo importante verso la semplificazione e
razionalizzazione di una
piattaforma potente ma controversa quale J2EE. Non avremo piu' Home
interface, Remote
interface e deployment descriptor, o almeno non avremo bisogno di sapere
che esistono.
Gli EJB saranno molto piu' simili ai POJO (Plain Old Java Object) e molto
piu' semplici
da gestire. In effetti queste informazioni erano disponibili gia' da un
po', ma vi
assicuro che vedere le cose in azione e' tutta un'altra cosa e si capisce
molto meglio
l'impatto!
- Tiger, J2SE 5.0. Due parole sulle prestazioni, eccezionali. La
tecnologia di sharing
della VM, inventata da Apple (gia' utilizzata per OSX con la VM 1.4.x) e'
eccellente
e aiuta veramente nella parsimonia delle risorse. Le nuove features
"sintattiche"
di Tiger sono invece note gia' da un po'. Per chi non le conoscesse gia',
un avvertimento:
il cambiamento e' in alcuni casi molto grande, quindi preparatevi anche a
cambiare
alcune abitudini ormai radicate! Un esempio su tutti, la concorrenza. La
keyword "synchronized"
e' non dico deprecata ma poco ci manca, il nuovo memory model, i tipi
atomici e soprattutto
l'integrazione delle librerie di Doug Lea all'interno del JDK aprono nuove
(alcune
finora addirittura impossibili) prospettive e possibilita' alle
appplicazioni multithreaded.
Piu' espressivita', piu' potenza, piu' performance, una costante che
ritroveremo molto
spesso.
- I giochi. Si e' visto il CGO di Sun (Chief Gaming Officer, che bel
lavoro...) mostrare
giochi all-java con 400 FPS su PC da 700$, e ci si comincia  a chiedere se
e' veramente
rimasto qualcosa che ancora non si possa fare con Java... (N.B. cosa
ovviamente diversa
dal dire che Java e' il miglior modo per farla) Il tutto, collegato alla
notizia di
ieri dell'open sourcing di Java3D e Looking Glass, apre prospettive
veramente interessanti.
- Jini. Jini e' vivo e vegeto, rintanato in una nicchia ma perfettamente
"alive and
kicking". Jini 2.0 mi fa sorgere dei dubbi esistenziali: e' ancora troppo
presto per
rivoluzionare il mondo del distributed computing? E' pensabile cominciare
a proporre
sistemi adattativi e fortemente distribuiti nelle realta' aziendali
italiane invece
delle solite soluzioni?
- Groovy. Really impressive. Per chi non lo conoscesse, Groovy e' un nuovo
linguaggio
per fare java-scripting, completamente object oriented e potentissimo (JSR
241) Ho
assistito alla presentazione di James Strachan, e sono uscito con la
sensazione forte
che finalmente non avremo piu' niente da invidiare a Smalltalk per
espressivita'.
Vi dico solo che "grep", in Groovy, si fa con... 1 (una) riga di codice. E
buonanotte
a parentesi e punti e virgola, "no more spoonfeeding the compiler".
Ovviamente Groovy
genera bytecode per la JVM...
- Cellulari e mobile. Non ho seguito gli speech relativi, ma mi dicono che
ci sono
molte buone notizie. Vado a sentire il presidente di Nokia nel keynote di
stamattina,
poi vi diro' di piu' :)
Per ora e' tutto, a domani!
Ugo Landini
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 alle appplicazioni multithreaded.
Sarà!
Comunque tutte le nuove librerie di Doug Lea piene di semafori,
sezioni critiche e amenità varie sulla concorrenza sono basate
alla fin-fine _sempre_ e _comunque_ su
    synchronized(obj) {
       ...;
       notify();
       ...;
       wait();
       ...
    }
Io temo che nascondere troppo un concetto così basilare
con librerie troppo complesse porti alla fine
ad utilizzare le librerie senza rendersi conto di cosa ci sia sotto.
Quindi poi sentiremo moltissimi nuovi-sviluppatori di Java
lamentarsi perchè la particolare classe di Doug Lea che loro usano
non funziona o non fa quello che si aspettano...
... invece, semplicemente, nel mare-magnum delle classi di Doug Lea
avranno scelto la classe sbagliata o non l'avranno opportunamente
usata!
Forse sono troppo pessimista, ma...
... staremo a vedere.
Comunque anch'io personalmente sto continuando ad usare
la vecchia e semplice synchronized perché sono "spaventato"
da tutte quelle classi nuove e non so valutare con precisione
quale mi serve.
Invece con
    synchronized(obj) {
       ...;
    }
e le relative notify() e wait() so sempre esattamente cosa succede!
- Dario (scettico)

 e le relative notify() e wait() so sempre esattamente cosa succede!
Beh, ci sono diversi algoritmi che NON erano possibili in Java prima della
1.5 per via del memory model 
BTW, ho parlato con il team del JSR relativo e mi hanno detto che non
potevano modificare la semantica di synchronized per ovvii motivi di
compatibilita', cosi' hanno preferito lasciare tutto nelle librerie
concurrent.
Questo perche' alcuni concetti avrebbero potuto tranquillamente essere
espressi con keyword o modifiche semantiche di wait, notify e compagnia
cantante. Pensa ad esempio alla limitazione del blocco sulle wait, mentre
ora ci sono diverse possibilita' per l'acquire di un lock in maniera piu'
sofisticata (ed utile)
Il consiglio che ti posso dare ' di non cercare di riscrivere le classi
concurrent, molte sono veramente difficili da fare "correttamente" e a
prova di errore. Il solo synchronized e' ovviamente insufficiente e troppo
di basso livello per esprimere i concetti piu' complessi del mondo
multithreaded.
 
uL


 multithreaded.
È qui che io e te non siamo d'accordo.
Per me _non_ è vero che synchronized+wait+notify sia insufficiente.
Per me con synchronized+wait+notify puoi fare tutto ciò che vuoi
nel mondo del multi-thread.
Non vorrei dire una bestialità ma tutte le mille classi
del nuovo package java.util.concurrent della 1.5 sono realizzate
alla fin fine direttamente in Java con synchronized+wait+notify.
Felice di essere smentito!
- Dario

 alla fin fine direttamente in Java con synchronized+wait+notify.
solo ORA, con la 5.0, puoi fare piu' o meno tutto quello che vuoi con
synchronized e company, per esempio... proprio implementare le concurrent
API. Ma il 99% delle persone non hanno gli skill per farlo. 
Ci sono classi nelle concurrent API che hanno avuto bisogno di Doug Lea,
probabilmente il nome piu' noto nel mondo accademico per quanto riguarda
le problematiche di concorrenza, un mondo di professori, diversi paper di
ricerca e il peer review della comunita' per avere la garanzia che tutto
fosse OK. (i problemi di concorrenza sono fra i piu' spinosi, anche per
gli esperti: non e' una banale questione di aver fatto l'esamino
all'universita')
Questo lavoro ha fruttato le concurrent API, che sono li' pronte per
essere utilizzate. Riscriverle e' fra il presuntuoso e il naive :)
Detto questo, mi potresti dire: io pero' non ho bisogno di costrutti piu'
complessi, perche' NON scrivo server heavily multithreaded, quello che
faccio e' semplicemente risolvere semplici problemi di concorrenza
"indotti" da server scritti da altri. Ossia, non implemento certo JBoss o
Tomcat, ma lo uso e basta.
Be', anche questo sarebbe falso.
Per esempio, ti potrebbe servire implementare una cache, che so, per un
directory server o un database o quello che ti pare. 
E' ovviamente chiaro (spero :)) che sarebbe naive  lockare una cache se
nessuno ci sta scrivendo, ma tutti i thread stanno solo leggendo. Hai
bisogno di un qualcosa che blocchi i thread in lettura solo se
effettivamente qualcuno sta scrivendo. Il problema e' semplice, utile
nella maggior parte dei progetti ma non banalissimo da implementare
(neanche troppo complesso, ma e' solo il primo esempio che mi e' venuto in
mente)
Ora hai una soluzione bella e pronta, performante quanto i maggiori
esperti sono riusciti a renderla, controllata come correttezza quanto i
maggiori esperti sono riusciti a controllarla, ecc.
Inoltre le nuove API permettono di scrivere dei test cases molto piu'
semplicemente. Uno dei problemi maggiori pre JDK 1.5 era proprio testare
la correttezza di applicazioni multithreaded, problema insormontabile e
molto sentito da chi utilizza TDD (per esempio gli XPers, ma non solo).
Ora gli wait non bloccanti, gli executors, ecc. aprono molte porte alla
testability di una applicazione multithreaded, e probabilmente bisognera'
riscrivere il capitolo "testing thing that are hard to test"!
HTH,
