Newsgroup: it.comp.java
Titolo: JDK5 - Il punto

Ciao a tutti,
tempo fa proposi sul NG questa discussione circa l'imminente (che poi 
tanto imminente non si rivelò :) uscita del JDK5, a quei tempi ancora 
JDK1.5:
http://tinyurl.com/7l57w
Oggi a qualche mese dalla comparsa della major release di Java sarebbe 
interessante capire come è la situazione nel panorama "javistico" italiano.
La mia idea/preoccupazione a quei tempi era che l'avvento della nuova 
versione del linguaggio avrebbe spaccato in due il panorama degli 
utilizzatori di Java: gli "entusiasti" (tra i quali, almeno 
tendenzialmente, il sottoscritto :)) che sarebbero subito passati al 
nuovo mondo, e i critici/conservatori, che avrebbero ritardato il più 
possibile questo passaggio.
Oggi aggiungerei anche la categoria dei "disinteressati": si tratta di 
quelli che sanno che il JDK5 esiste, hanno un'idea di cosa abbia di 
nuovo, ma "tanto da noi non si usa"...
Questa qui, almeno tra le persone con cui lavoro più di frequente, mi 
sembra anzi la categoria più larga, il che francamente mi lascia un po' 
perplesso...
All'estero la situazione sembra un po' diversa, per esempio su 
comp.lang.java.object la frequenza dei post inerenti il JDK5 aumenta di 
giorno in giorno, mentre qui discussioni su generics & company sembrano 
ancora una rarità.
Da voi come va? E' avvenuto il salto? Ci si prepara ad effettuarlo? Se 
sì come? Se no perché?
Ciao
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://www.sourceforge.net/projects/ammentos
http://ammentos.biobytes.it

 
http://tinyurl.com/7l57w
Per quel che può valere il mio contributo: quando sarà disponibile la
versione J2EE 1.5, con EJB 3.0, senz'altro spingerò
per il "salto" anche in azienda.... Per quel che mi riguarda, non ho ancora
studiato le nuove funzionalità / feautures della versione Tiger.
Spero di colmare a breve questa lacuna.....
Scorpio.


http://csvtosql.sourceforge.net/

 da noi siamo gią passati a java tiger.
posso chiederti in quale ambito applicativo lavorate (web, 
client/server, applicativi desktop...)?
Hanno organizzato dei corsi di aggiornamento o vi siete mossi da soli 
(come ho dovuto fare io)?
ciao e grazie


 studiato le nuove funzionalità / feautures della versione Tiger.
Sì, anche questo del J2EE è un altro aspetto interessante. Qui la 
tentazione a rimandare il discorso, in genere già più forte rispetto 
agli altri ambiti, è anche sostenuta dal classico ritardo tra l'SDK e la 
versione entreprise. Comunque quale sarà l'andazzo lo si dovrebbe già 
intuire dai discorsi dei boss :)


 client/server, applicativi desktop...)?
Posso "girare" la stessa domanda anche a te, Pole ?
Scorpio.

 Posso "girare" la stessa domanda anche a te, Pole ?
Certo :)
Nell'azienda in cui lavoro ci occupiamo di applicativi e servizi web, 
prevalentemente basati su Tomcat. Io in particolare sono dedicato al 
design e implementazione di webservice di pagamento elettronico e 
utilità varia. Generalmente il mio compito è quello di costruire API per 
interfacciare risorse remote di vario tipo.
Per conto mio invece mi occupo di quella che è sempre stata la mia vera 
passione: applicativi di rete con client grafici. Ecco perché adoro swing :)


 :)
Qua la mano, socio. :-D
Sto sviluppando per mio conto un client mysql grafico ...
-- 
Ciao,
 Fabrizio
=== 
http://www.negusweb.it
 ===

 (come ho dovuto fare io)?
no, qui non c'è nessun corso di aggiornamento.
e cmq si fa prima a studiare da soli. :)


 sě come? Se no perché?
I prodotti J2ee Sun da poco girano su Java 5, comunque č normale che i
clienti grandi abbiano dei "tempi tecnici".
Per la cronaca, finora non ho ancora visto un cliente Sun che usi Java5,
proprio per i motivi che elencavi prima (ovviamente parlo solo di
esperienze personali)
Siamo molto indietro, e jdk 1.4 non č stato ancora ben assorbito dai piů.
Se il ritmo italiano č questo, fra poco saremo due versioni indietro. E
speriamo solo di java...
uL
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Sto sviluppando per mio conto un client mysql grafico ...
Eeeh si fa presto a dire client mysql :P Di che si tratta? E' 
multiutente? E' commerciale o free? E soprattutto è fatto col JDK5? :))


 speriamo solo di java...
 >
 > uL
 >
Ciò che dici non è bello :-/
Di questi tempi si parla tanto di competitività; non è possibile essere 
competitivi se non c'è una costante spinta ad aggiornarsi e a 
migliorarsi. A maggior ragione IMHO questo vale in settori dinamici come 
il nostro in cui la concorrenza è così agguerrita.
Ora, se questo avviene nel mondo delle imprese, cosa dobbiamo aspettarci 
dalla scuola e dalle istituzioni, notoriamente ancora più lente?
Relativamente ai clienti Sun puoi confermare la mia impressione che 
all'estero stia andando un po' meglio che qui?
ciao
Pole


 all'estero stia andando un po' meglio che qui?
non ho feedback al proposito, mi informo un po' e vi faccio sapere


 gran passo) e risorse economiche
Mi viene in mente un bel business... ma alla Sun ci avrete sicuramente 
già pensato ;)
pole


Scusate la mia grande ignoranza ..
mi sono accostato a questo linguaggio da poco ed ereditando un software 
già scritto con la jdk1.3
Noi facciamo software di tipo gestionale, quindi molta gestione del 
database, abbastanza interfaccia grafica e pochissimo web.
Inoltre il nostro software gira su macchine di scarse prestazioni (casse 
IBM).
Vi volevo chiedere se, secondo voi, ci sono degli aspetti che è 
consigliabile verificare sulla versione 1.5 oppure se conviene rimanere 
dove siamo.
Cioè sulla 1.5 ci sono sensibili miglioramenti sulle prestazioni o 
sull'interfaccia grafica o sulle prestazioni che mi dovrebbero spingere 
a passare alla nuova versione???
Grazie a chi mi vorrà dare qualche consiglio ....
pole ha scritto:


 dove siamo.
Entrambi.
Quando esce l'aggiornamento di una piattaforma č buona norma valutarla 
sempre. Questo non significa fare aggiornamenti a tappeto sul pregresso.

 a passare alla nuova versione???
Ciao Daniele, il punto per cui ho proposto questo thread č proprio 
questo: immagino che per l'azienda per cui lavori il codice sia il 
capitale piů prezioso, come č normale che sia. Di conseguenza sarebbe 
nel suo interesse mantenerlo sempre al passo in modo da non trovarsi con 
gli anni messi fuori dal mercato.
I motivi per cui rimanere indietro sono IMHO pericolosi in tal senso 
sono vari: prestazioni generalmente inferiori, difficoltŕ a trovare 
strumenti (librerie, ambienti di sviluppo etc.), supporto del linguaggio 
sempre piů ridotto etc, senza sottovalutare l'impatto in termini di 
immagine verso la clientela (soprattutto quella da conquistare).
Insomma, al di lŕ di tutte le considerazioni (comunque valide e a favore 
del JDK5) relative a performace e grafica, soprattutto un investimento 
contro la perdita di valore del capitale aziendale. Un po' come quando 
si mettono in regola i vecchi palazzi con le nuove norme insomma :)


 si mettono in regola i vecchi palazzi con le nuove norme insomma :)
Quel che dici è sacrosanto, però è anche vero che la compatibilità
all'indietro in Java è decisamente buona, se non ottima... forse sono
ingenuo, ma non credo che il passaggio da jdk 1.4.x a 1.5.0 possa essere
così traumatico... eccezion fatta per la grafica.
Scorpio.

 così traumatico... eccezion fatta per la grafica.
Come la vedo io: la compatibilità è quella che permette alle vecchie 500 
di continuare a percorrere le stesse strade delle moderne automobili. 
Ciò non toglie che viaggiare su una Ferrari F50 sia tutt'altro viaggiare ;)


E' anche vero che l'investimento per comprare una ferrari F50 deve avere 
dei ritorni che, a livello aziendale, permettano di giustificarli.
Se io devo investire una decina di giornate uomo per la formazione e per 
capire le potenzialità del nuovo linguaggio più 30 giornate uomo per 
"convertire" il codice alla nuova versione, mi tovo davanti al problema 
di giustificare al mio amministratore questo investimento che non si può 
risolvere unicamente ad un "abbellimento" dell'applicazione.
Se di contro ottengo una applicazione più performante o .... qualcosa 
cambia tutto.
A tutti piacerebbe avere un software sempre ultra aggiornato all'ultima 
versione, ma non sempre è compatibile con le esigenze aziendali.
Ad esempio tempo fa abbiamo acquistato la versione 8 di Delphi (eravamo 
rimasti inchiodati alla v. 6), per poi scoprire che passare alla nuova 
versione avrebbe richiesto, stima approssimativa, circa 20-30 gg./uomo.
Inoltre quando metti mano così pesantemente al codice ti ritrovi con un 
software che non è più testato ed affidabile come era in principio.
Morale della favola ... è vero che bisogna essere al passo con i tempi, 
ma bisogna anche farlo con la giusta modalità e con le giuste motivazioni.
Che ne pensate voi??
pole ha scritto:


 dei ritorni che, a livello aziendale, permettano di giustificarli.
correttissimo
Inoltre una precisazione fondamentale è che al 99% il bytecode funge così
com'è sulle nuove VM e beneficia delle prestazioni e di diverse feature
aggiunte "automaticamente"
Rivedere il codice esistente deve darti invece ALTRI benefici, ed il costo
è solitamente alto (è un porting vero e proprio). E' facile che per
sfruttare le nuove caratteristiche si debba riscrivere interi package. Un
esempio ce lo potrebbe fare proprio pole che ha usato i meta per il suo
tool di mapping, in pre 1.5 si sarebbe dovuto usare xdoclet, xml custom o
altro per fare le stesse cose: chi ci si mette, a prodotto finito, a
spendere tempo considerevole per il porting se questo non da benefici
misurabili sulle altre feature? Se ovviamente il codice custom è di per
se' costoso, potrebbe essere relativamente semplice ottenere le risorse
finanziare per il porting. Se poi il codice è particolarmente malleabile e
si può rifattorizzare con poco sforza è ancora meglio :)
ciao


 tool di mapping,
[CUT]
Nasce una domanda: a livello pratico, e non teorico, quali sono i benefici
di 1.5 ? Non è così facile rispondere, secondo me. Per esempio chi sviluppa
J2EE sa, ad esempio, che non potrà avvalersi delle nuove caratteristiche del
multithreading, perchè in ambito J2EE l'uso esplicito dei Thread è
tabù.Quindi, dal punto di vista di questa tipologia di  sviluppatori cambia
poco tra 1.4 e 1.5 sotto quest'aspetto, senonchè probabilmente le nuove api
per il multithreading favoriranno lo sviluppo di Application server più
performanti. Chi usa Java per sviluppare GUI portabili, non attenderà con
ansia le specifiche semplificate degli EJB.
Scorpio.

 
Eh, no! Qui devo proprio intervenire...
Il passaggio "nudo e crudo" da una versione di JVM a quella successiva è 
sempre problematico, e chiunque abbia provato a farlo in ambito 
_professionale_ può confermarlo!!!
Sono sicuro che gli ingegneri della Sun (o di qualunque azienda 
produttrive di JVM) hanno fatto grandi sforzi per mantenere la 
compatibilità all'indietro, ma non è umanamente possibile manterla al 
100% anzi, siamo ben al di sotto :)
Il caso tipico è un'applicazione gestionale: molte funzionalità, 
moltissimo codice, workaround e trucchetti vari (dovuti spesso a bug 
delle librerie o della JVM). La prendi così com'è e la fai girare su una 
JVM nuova: nel 99% dei casi avrai dei problemi già alla prima schermata! 
Se poi fai girare qualche unit test scopri poi che altre funzionalità 
(per lo più legate alle librerie standard o di terze parti) non vanno più...
Secondo me:
- è giustificata (anzi, è auspicata) la prudenza da parte delle aziende 
riguardo al passaggio da una versione a un'altra;
- bisogna comunque aggiornarsi al nuovo: con calma, senza 
stravolgimenti, tanto prima o poi si riesce a verificare tutto e 
l'applicazione girerà più velocemente, si avrà accesso a librerie più 
recenti, il codice dell'applicazione si raffina, ecc.
Peace & Love,
Dimitri
-- 
  -- + Setaceous Pig + --
http://megadix.users.mcs2.netarray.com/
http://www.jroller.com/page/megadix/

 si può rifattorizzare con poco sforza è ancora meglio :)
Esatto :)
So che spesso è un obbiettivo difficile da ottenere, ma secondo me nella 
costruzione del codice bisognerebbe sempre tener presente il divenire 
delle cose. Il metodo XP consente di ottenere buoni risultati in questo 
senso.
Una progettazione guidata dai pattern, tenendo ben solida l'idea di 
"incapsulare il concetto che cambia" e di tenere basso il livello di 
accoppiamento tra le classi come GoF insegna, è IMHO un approccio al 
contempo umile ed efficace per ottenere un sistema aggiornabile in modo 
relativamente semplice. Per "umile" intendo che non si abbia l'arroganza 
di pretendere di sapere oggi dove andrà il mondo domani.
Un sistema facilmente smontabile è anche facilmente aggiornabile, perché 
l'aggiornamento può procedere per gradi dalle parti più urgenti verso 
quelle meno urgenti. Alcune parti possono anche rimanere al vecchio 
stile, specie se opportunamente impacchettate in librerie esterne.
Ecco anche perché nei miei progetti cerco di non legarmi mai mani e 
piedi a particolari soluzioni, e quando devo sceglierne una cerco di 
tenerla il più possibile "lontana" dal core.
Per esempio nel caso del mio tool di mapping (che certo non sarà un 
esempio di art of programming :)) c'è una sola classe che effettivamente 
utilizza i metadata. Questo potrebbe consentirmi in futuro di aggiungere 
nuove modalità di mapping senza dover rivedere tutto il codice.
Io considero il software un po' come un organismo vivente, che evolve 
giorno dopo giorno e deve avere una struttura vitale tale da garantirgli 
di sopravvivere nella casistica più ampia possibile di condizioni 
esterne. Noi programmatori siamo i "demiurghi"; il tool di refactoring e 
junit i nostri strumenti :)
ciao


 100% anzi, siamo ben al di sotto :)
Beh, vorrà dire che sono stato finora molto, molto fortunato ;-)
Scorpio.

Per la mia brevissima esperienza in Java devo dire che ho incontrato 
anche io i miei bei problemi di porting da una versione all'altra.
Come ho detto prima ho ereditato un applicativo scritto sulla jdk1.3 ed 
ho dei pulsanti che sono stati implementati con l'aggiunta di alcune 
informazioni.
Ricompilando tutto il pacchetto con la versione 1.4 quando premo un 
pulsante non accade assolutamente nulla .. non ho neanche nessun tipo di 
eccezione, ma molto semplicemente è come se non fosse mai stato premuto.
Non ho ancora avuto modo di controllare e debuggare a fondo 
l'applicativo perchè in altre faccende affaccendato ... ma è già un 
esempio che bisogna andare con i piedi di piombo a fare questo tipo di 
porting specialmente se si hanno qualche centinaio di installazioni 
sparse per l'Italia .....
Dimitri De Franciscis ha scritto:


 eccezion fatta per la grafica.
Scusa l'ignoranza ma cosa cambia per la grafica in Java 1.5 ?
-- 
Ciao
Fabio

 _professionale_ può confermarlo!!!
se parliamo di Swing, confermo. Applicazioni server-side, no. Mi è
capitato spesso il porting automatico, senza toccare neanche una riga di
codice.
Qualche volta mi sono capitate cose noiose tipo l'introduzione
dell'assert, e pochissime volte ho avuto problemi di entità consistente.
Chiaramente avere una bella batteria di unit test aiuta sempre :)
BTW, si fa per parlare :)


 junit i nostri strumenti :)
mmm... sento l'influenza del metodologo di Sutri nelle tue parole ;)
a Java Conference di quest'anno avremo un'intera track sul refactoring.
Partecipa anche tu numeroso!


 Scusa l'ignoranza ma cosa cambia per la grafica in Java 1.5 ?
Sperando che Pole non mi fulmini (essendo lui un aficionado della grafica in
Java): in genere, tra una release e l'altra del JDK la parte che "soffre" di
più di scarsa portabilità è proprio quella connessa alla grafica, proprio
per motivi di implementazione di swing + awt, legati alla gestione degli
eventi ed al modello multithreaded della grafica in Java.... Personalmente,
il front-end grafico del programma della mia tesi di laurea  girava
benissimo su 1.2.1, mentre su 1.2.2 dava seri problemi di refresh.
In particolare su Java 1.5 ho letto che la grafica si appoggerà molto più
pesantemente di prima su librerie (dll o so) native.
Scorpio.

 codice.
E' quanto intendevo io. Esempio ? Applicazioni J2EE deployate da un
appserver J2EE 1.3 allo stesso appserver (versione successiva) con  J2EE 1.4
senza mal di testa nè bagni di sangue....
Poi, ovviamente: se con J2EE 1.5 la musica cambierà, ora non so dirtelo....
Scorpio.

 pesantemente di prima su librerie (dll o so) native.
Sì, ma che io sappia non a livello di componenti grafici (che continuano 
a rimanere -per fortuna - lightweight), quanto di accelerazione grafica, 
threading etc. Ho letto su 
java.sun.com
 che la prossima versione 
(Mustang) dovrebbe portare grosse migliorie in questo senso. Pare che 
riusciranno a far scomparire il fantomatico rettangolo grigio che da 
sempre precede di qualche frazione di secondo il disegno delle finestre 
in Java.


 Partecipa anche tu numeroso!
Il nostro Jug sta organizzando una "spedizione"... quasi quasi... :))


> mmm... sento l'influenza del metodologo di Sutri nelle tue parole ;)
Ops! Non avevo ancora notato che c'è anche una sessione sua, oltre che 
(ovviamente) del dott. Landini e del dott. Bossola :)
Credo sarà un jc davvero interessante...


 multiutente? E' commerciale o free? E soprattutto è fatto col JDK5? :))
Multiutente? Un client?
Lo sto sviluppando per affinare le mie conoscenze di Java, Swing e design
pattern. Totalmente free.
Spero di inserirlo nei prossimi giorni sul mio sito.
-- 
Ciao,
 Fabrizio
=== 
http://www.negusweb.it
 ===