Dopo i primi programmi in BASIC e l’esperienza di JavaMeteo, un nuovo progetto: costruire piccole librerie Java, riutilizzabili e disponibili anche per altri programmatori.
Un modo diverso di vedere il codice
All’inizio degli anni Duemila Java era ormai entrato stabilmente tra i linguaggi con cui mi piaceva sperimentare.
Avevo iniziato a programmare dieci anni prima, nel 1991, sul mio vecchio 286. Dal BASIC ero passato alla realizzazione di programmi più articolati, fino a scoprire con Java la programmazione orientata agli oggetti.
L’esperienza universitaria di JavaMeteo mi aveva permesso di confrontarmi con applicazioni distribuite, thread, database e comunicazione tra componenti software.
Ma c’era un altro aspetto della programmazione che cominciava a interessarmi particolarmente: perché riscrivere ogni volta qualcosa che avevo già realizzato?
Se un programma aveva bisogno di verificare un codice fiscale, controllare una data o gestire una particolare interfaccia grafica, poteva essere utile disporre di una classe già pronta. E magari quella stessa classe avrebbe potuto servire anche a qualcun altro.
Da questa filosofia prese forma Java Island.
Una piccola isola di componenti Java
Java Island non era un’applicazione tradizionale, con un unico scopo e una schermata principale.
Era piuttosto una raccolta di classi che affrontavano problemi differenti, accomunate dall’idea di poter essere inserite in altri programmi.
Tra i componenti che realizzai c’erano classi per verificare la correttezza di codici fiscali e partite IVA, controllare codici EAN13 e ISBN, elaborare date e stringhe. Altre classi erano dedicate alle interfacce grafiche realizzate con Swing.
L’obiettivo era creare una piccola libreria personale, organizzata e documentata, dalla quale attingere quando si presentava una nuova esigenza.
Oggi l’idea sembra quasi scontata. All’epoca, per me, significava fare un passo avanti: non pensare soltanto al programma che stavo scrivendo, ma anche ai componenti che avrei potuto utilizzare in futuro.
Un esempio: controllare il codice fiscale
Uno dei componenti di Java Island si chiamava semplicemente CF. La sua funzione era verificare la correttezza formale di un codice fiscale italiano.
L’utilizzo era molto semplice:
if (CF.isValid("stringa con il codice fiscale")) {
// Il codice fiscale è formalmente valido
}Dietro quella singola chiamata c’erano diverse operazioni: normalizzazione della stringa, controllo della lunghezza e calcolo del carattere di controllo.
La classe non verificava se una persona con quel codice fiscale esistesse realmente. Verificava soltanto la correttezza formale del codice.
Ed era proprio questo il vantaggio. Chi utilizzava la libreria non doveva conoscere tutti i dettagli dell’algoritmo. Gli bastava richiamare un metodo e utilizzare il risultato.
Una piccola dimostrazione di un principio importante della programmazione orientata agli oggetti: nascondere la complessità dietro un’interfaccia semplice.
DoubleJList: anche le interfacce possono essere riutilizzate
Un altro componente che oggi trovo particolarmente rappresentativo è DoubleJList.
Avevo realizzato una classe Swing per gestire due liste affiancate, consentendo di spostare elementi da una all’altra attraverso appositi pulsanti.
Era un tipo di interfaccia abbastanza comune nei programmi di quel periodo. Penso, per esempio, alle finestre di configurazione nelle quali si sceglievano i campi da visualizzare o le funzionalità da attivare.
Anziché costruire ogni volta da zero pulsanti, liste e relativa gestione degli eventi, volevo poter riutilizzare un componente già predisposto.
Rivedendo oggi i sorgenti, mi colpisce la cura nella descrizione del funzionamento e dei parametri. Non era soltanto una questione di far funzionare il codice: stavo cercando di costruire qualcosa che potesse essere compreso e utilizzato anche al di fuori del programma per il quale era stato pensato.
L’importanza della documentazione
Un dettaglio particolarmente interessante del progetto è proprio la documentazione.
Nei sorgenti compaiono descrizioni delle classi, spiegazioni dei metodi, parametri ed esempi di utilizzo.
È evidente anche l’attenzione all’organizzazione dei componenti in package distinti, come island.util, island.util.ita e island.swing.
Il progetto comprendeva inoltre un archivio Java, island10.jar, destinato a raccogliere le classi compilate.
Per me rappresentava un modo più maturo di progettare software. Il codice non doveva soltanto funzionare sul mio computer. Doveva avere una struttura comprensibile e possibilmente essere utilizzabile anche in altri contesti.
Java Island aveva anche un sito
Nei commenti dei sorgenti compare un particolare che mi ha fatto sorridere: www.geocities.com/javaisland2001. Era il riferimento al sito Web che avevo associato a Java Island.
Ritrovarne uno snapshot conservato su Wayback Machine è stato come aprire una finestra sull’Internet dei primi anni Duemila.
La pagina mostrava il titolo Java Island Project, la scritta Java Resources, una sezione «Risorse» dedicata ai principianti, alle utilità, allo sviluppo e ai collegamenti, oltre a una colonna «Novità» con notizie sull’ecosistema Java.
Nell’immagine archiviata compare anche la data dell’ultimo aggiornamento: 13 settembre 2003. Era una pagina personale vera e propria, non soltanto un deposito di sorgenti.
GeoCities appartiene a un’epoca molto diversa da quella attuale: un Internet fatto di pagine personali, piccoli progetti indipendenti e spazi nei quali condividere interessi e sperimentazioni.
Oggi siamo abituati a piattaforme come GitHub, dove pubblicare codice, documentazione e progetti è diventato estremamente semplice. All’epoca realizzare uno spazio Web dedicato a una propria raccolta di librerie era già parte dell’esperienza.
Non c’era soltanto il desiderio di scrivere qualcosa. C’era anche quello di metterlo a disposizione.
Dalla condivisione al software open source
Java Island rappresentò per me anche un avvicinamento concreto alla filosofia del software aperto e riutilizzabile.
L’idea di fondo era semplice: un programma o una libreria non devono necessariamente rimanere confinati nel computer di chi li ha scritti. Possono essere studiati, utilizzati e, nel rispetto delle condizioni di licenza, modificati o migliorati.
Ripensandoci oggi, è un principio che ritrovo in moltissimi strumenti che utilizzo quotidianamente. L’ecosistema del software moderno si regge in larga parte sulla disponibilità di componenti, librerie e progetti sviluppati da altre persone.
Con Java Island, nel mio piccolo, avevo cominciato a ragionare nella stessa direzione.
Venticinque anni dopo
Oggi i sorgenti di Java Island sono disponibili nel mio repository GitHub.
Alcune delle classi che scrissi allora possono apparire superate. Le librerie standard si sono evolute, i linguaggi hanno introdotto nuove funzionalità e molte operazioni si realizzano oggi in modo diverso.
Ma riguardando quei file non mi interessa tanto stabilire se siano ancora utili nella loro forma originale. Mi interessa soprattutto ritrovare l’idea che li aveva ispirati.
Un problema risolto bene può diventare uno strumento per affrontarne molti altri.
È un principio che continua ad accompagnarmi anche oggi, quando sviluppo automazioni con Excel, VBA, Power Query o Python.
E forse è proprio questo il filo che unisce il vecchio BASIC, JavaMeteo, Java Island e i progetti attuali. Non tanto il linguaggio utilizzato, quanto il desiderio di costruire strumenti che semplifichino il lavoro.
In fondo, Java Island era una piccola raccolta di classi Java. Ma per me rappresentava qualcosa di più: il passaggio dal semplice piacere di programmare a quello di creare qualcosa che potesse essere utile anche ad altri.
Il codice sorgente originale è disponibile su GitHub – Java Island. Il vecchio sito è visibile nello snapshot di Wayback Machine.
Lascia un commento