|
Quando,
qualche hanno fa, Microsoft lanciava sul mercato un prodotto
in versione 1.0, il pubblico sia utente che tecnico, poteva
star certo che in quella versione sarebbero state presenti
molte anomalie. Tutti sapevano che in realtà, la versione
1.0 possedeva una qualità simile a quello che l’utente
si aspettava in una versione beta. D’altra parte, molte
volte è più utile, al fine di conquistare quote
di mercato, rilasciare un software imperfetto prima, che più
raffinato con mesi di ritardo. E’ l’altra faccia
della medaglia della concorrenza: se da una parte spinge a
produrre prodotti sempre nuovi ed a costi inferiori, dall’altra
riduce i tempi ed il budget di spesa relativo per la loro
realizzazione.
Ad un certo punto Microsoft adottò uno schema di versionamento
diverso, forse a partire da Windows 95; a questo sono seguirono
Windows 98, Windows 2000, Office 97, ed altri. La sensazione
che suscita nell’acquirente questo schema è che,
se ora siamo nel 2004 ed acquisitiamo un prodotto dal nome
GeniusPlatform 2004, abbiamo la sensazione di comprare qualcosa
di moderno ed attuale, mentre se pensiamo a Windows 2000,
ci sembra qualcosa di vecchio ed antiquato, e forse siamo
spinti ad acquistare la nuova versione.
Oggi Microsoft, ed altri produttori, sono innamorati della
lettera X, molto probabilmente ispirati da Mac OS X di Apple
che, sebbene veda sempre ridursi la sua quota di mercato del
5% (aumentando il numero totale di macchine vendute nel mondo
e rimanendo sostanzialmente uguale quello venduto da Apple,
la sua quota percentuale si riduce), sembra lo stesso fungere
da traino ed ispiratore per molte altre aziende. Da qui Windows
XP, Office XP ed altri.
Lo
schema classico
Sul versante Unix, la numerazione dei programmi ha invece
mantenuto, più che su altre piattaforme, la convenzione
di versione basata su tre numeri separati da punti, come ad
esempio 1.5.4. Il significato di ciascuna di queste cifre
è ben definito: la prima è il numero principale
di versione, la seconda quello di sottoversione, e la terza
è il numero di revisione. Semplificando, si può
dire che il primo numero cambia quando il programma viene
riscritto da zero, oppure subisce modifiche sostanziali e
diffuse; il secondo cambia invece all’aggiunta od alla
modifica di funzioni. Il terzo dovrebbe essere riservato alle
versioni di manutenzione, che non aggiungono nessuna funzionalità,
ma che correggono anomalie di funzionamento.
Fino ad oggi, anche la piattaforma Java, che Unix non è,
ma non è neanche Windows, ma è qualcosa al di
sopra di questi sistemi operativi ed altri, seguiva abbastanza
fedelmente questo schema di numerazione. E’ vero, il
nome del prodotto è passato da Java a Java2, ma se
si guardano le versioni dell’SDK troviamo:
-
1.0.2
- 1.1
- 1.2
- 1.2.1
- 1.2.2
- 1.3
- 1.3.1
- 1.3.2
- 1.4
- 1.4.1
- 1.4.2
Forse
ne ho dimenticata qualcuna, ma è comunque evidente
che lo schema di numerazione seguiva il metodo standard.
Qual’è il vantaggio di questo schema di numerazione?
Il fatto è che una versione definita da tecnici, per
far capire ad altri tecnici l’entità delle differenze
rispetto al passato, e di conseguenza suggerire, nel caso
di salti di versione significativi, la necessità di
approfondire la documentazione della nuova release, eseguire
verifiche di compatibilità, o intraprendere altre azioni
opportune. Insomma: passare da Java 1.1 a 1.4 indica un bel
salto, mentre è chiaro che da 1.4 ad 1.4.1 le modifiche
sono minime e probabilmente solo correttive.
I
trucchi del marketing
Anche in passato, quando lo schema di numerazione classico
era molto più in voga, l’ufficio marketing ci
metteva becco, ed obbligava il team di sviluppo a rilasciare
una certa versione, magari la successiva della 1.1, come 3.0
o 4.0, per evidenziarne le sostanziali differenze rispetto
al passato. Lo schema numerico vedeva dunque impropriamente
utilizzato per dare all’utente la sensazione che la nuova
versione fosse radicalmente diversa dal passato. Bene per
il marketing, ma negativo per l’utilizzatore, che ne
poteva uscire confuso.
Dopo quasi dieci anni di versioni della piattaforma Java,
anche SUN è caduto in questo tranello, rinominando
la nuova versione di Java in preparazione - e prevista in
rilascio FCS (First Customer Service) il 30 settembre - da
1.5 a 5.0.
Non stupisce dunque che questa mossa di SUN abbia suscitato
sorpresa, dubbio e qualche polemica.
Novità
e sfide
Dunque, questa versione 5.0 dovrebbe essere un salto in avanti
notevole rispetto alla versione 1.4 ma, sebbene le novità
siano tante, non sono state evidentemente sufficienti a giustificare
un così ampio cambio di versione, dato quello che si
sente in giro per la rete.
Java 5.0 implementa diverse nuove funzionalità, in
particolare nella struttura del linguaggio e sono orientati
alla semplificazione della programmazione. Le novità
principali sono state discusse in un precedente articolo [1].
Java 5.0 cambierà sicuramente il modo in cui scriviamo
programmi Java, anche se probabilmente non da subito, visto
che per vari motivi in diversi ambienti si rimane vincolati
ad una specifica versione. Ad esempio, se la vostra piattaforma
per applicazioni Web è WebSphere 4.0, siete ancora
vincolati a Java 1.3...
Ma Java 5.0 è anche una sfida: non solo sono state
apportate modifiche alla struttura del linguaggio, che per
diversi anni aveva mantenuto la medesima sintassi, ma con
questo rilascio sono state aggiunte nuove funzioni nella libreria
di base, espandendone la dimensione ulteriormente. La sfida
si rinnova e mi fa pensare a due cose.
La
prima è che conoscere Java 5.0 diventerà presto
una necessità, e sarà sempre meno possibile
proporsi come “Sviluppatore Java” in generale: la
piattaforma sta diventando così vasta da richiedere
più specializzazione. Nasceranno dunque esperti Java2D,
di networking, di elaborazione matematica o di profiling.
Aumenteranno dunque il numero di esperti che magari conoscono
uno specifico settore, oppure, nel migliore dei casi, di qualcuno
di questi.
La
seconda. E’ necessario notare che alcune nuove funzionalità
si sovrappongono a quelle esistenti, e diventa possibile implementare
una data funzione in diversi modi. Una entropia che si è
andata creando all’interno della piattaforma Java nel
corso delle release, e che è attualmente un effetto
collaterale dell’evoluzione del software.
Forse il futuro ci porterà un qualche meccanismo per
nascondere le funzionalità ed i package deprecati all’occhio
del programmatore principiante. Questo aspetto, unito ad una
riorganizzazione dei package (package alias?) potrebbe aiutare
a ridurre l’entropia della piattaforma, nello stesso
mantenendo l’insieme delle funzionalità evolute
che nel tempo sono state realizzate.
Immaginate un menù Start di Windows XP applicato alle
API di Java: compaiono solo le cose più utilizzate
dall’utente corrente, vengono evidenziate le novità,
ed i dettagli interni sono nascosti all’osservatore.
Si pensi alla classe ImageIO: tutte le diverse funzionalità
sono distribuite in molte classi, ma in realtà per
leggere o scrivere una immagine è sufficiente utilizzare
metodi statici di una sola classe: perchè le classi
aggiuntive non possono comparire (nella documentazione?) solo
quando effettivamente richieste dal programmatore?
In questo modo aprire la documentazione HTML di Java 5.0 non
sarebbe più motivo di timore per il non esperto, che
non si troverebbe più di fronte alla descrizione di
qualcosa come 3500 classi e 40.000 membri.
Ed
il desktop?
Ma nonostante tutte le migliorie, anche in questa versione
viene ribadita la scarsa attenzione di SUN verso l’utilizzo
di Java per il desktop, nonostante siano stati fatti interventi
migliorativi in tutta l’area della grafica; da più
parti infatti si invoca la soluzione del bug 4924220, che
impedisce alle applicazioni Java di disegnare elementi testuali
in modo pulito e preciso, rendendo immediatamente distinguibile
una applicazione Java da una nativa.
Bibliografia
[1] Andrea Gini, “Java2 Standard Edition 1.5 beta 1”,
Mokabyte 3/2004 http://www.mokabyte.it/2004/03/jdk1_5.htm
|
