Syvo3

Il codice incriminato:

public class Test {
    public static void main(String[] args) {
        String a1 = "test";
        String a2 = "test";
        System.out.println(a1 == a2);
        a2 = new String("test");
        System.out.println(a1 == a2);
    }
}

Il primo confronto ritorna true, mentre il secondo false: ora, io avevo sempre pensato che una stringa inizializzata nel primo modo fosse semplicemente una scorciatoia al posto di new, invece a quanto pare sono due cose profondamente diverse. Il primo confronto dovrebbe, a norma di legge, confrontare i riferimenti, non i contenuti, ed invece non è così (nonostante i due oggetti siano dichiarati separatamente).

Perchè l’ho chiamato tradimento? Bè, perchè questo viola chiaramente il presupposto degli oggetti in Java: per quanto le stringhe siano un tipo base, sono comunque oggetti a tutti gli effetti, o almeno lo erano prima di questa scoperta… inutile dire che vale lo stesso fattaccio anche per gli oggetti che incorporano i tipi base (Integer vs. int). Questo dimostra comunque che conviene usare equals, dato che se una stringa viene ricreata l’== non funziona più, ma resta un notevole pacco.

Un ringraziamento a Maintux, che ha insinuato il seme del dubbio, ed a Sante che ha condiviso un’istanza di Eclipse all’uopo.

Read Full Post »

Ho appena letto due articoli molto interessanti da IBM DeveloperWorks: dato che si sta ormai festeggiando il ventennale di Java, è d’uopo un’analisi dello stato del linguaggio di programmazione (ormai vicino alla sua settima major release) e del mondo che lo circonda, specie a seguito del passaggio di proprietà da Sun ad Oracle (e prima ancora, del suo rilascio sotto licenza libera), per vedere se e quale futuro ci può essere. Penso che tutti i miei 10 lettori sappiano che Java è il mio linguaggio di programmazione preferito in assoluto, e quindi non posso esimermi dal riportare alcuni dettagli interessanti (per quanto vi consigli comunque la lettura perlomeno del primo dei due articoli stessi).

Riflessioni dagli utilizzatori

Nel primo articolo, l’autore convoca una sorta di tavola rotonda digitale, in cui chiede ad alcuni sviluppatori vicini al mondo DeveloperWorks il loro parere sulle questioni sul piatto di Java in questo 2010; in linea generale, l’aspetto positivo che emerge è la varietà di approcci, framework e librerie che si sono sviluppate non tanto e non solo intorno a Java, ma intorno alla sua Virtual Machine, in modo tale che alcuni dei difetti che emergono per Java stesso sono magari già superati da altri approcci compatibili (da un punto di vista di API) ma allo stesso tempo molto diversi (come produttività); alcune risposte emerse degne di osservazione:

• il primo difetto di Java è l’ammontare di codice necessario per fare qualunque cosa (assolutamente sperimentato anche da me, nel mio piccolo, specie nelle tecnologie usate quest’anno a Sistemi Distribuiti (vero, Sante?)): il futuro inevitabilmente si sposta verso quei framework che sono in grado di sviluppare rapidamente (Agile alla fin fine, Rails in altre parole) e che permettano all’informatico di concentrarsi sulle (famigerate) parti funzionali del prodotto, ed ignorare il più possibile le non funzionali (vedi i behaviour di Erlang); da questo punto di vista, alcuni passi avanti sono già presenti in Java 7 (vedi secondo paragrafo), altri erano già nati in librerie collaterali, altri già sono usabili sulla JVM.
• Le preoccupazioni verso Oracle sembrano essere venute meno, anche se si teme un po’ per il mondo Open Source (e già c’è stato l’esempio di OpenSolaris, su cui non approfondisco ulteriormente per non uscire dal tema) e sul fatto che alcune delle cose, che sono sempre state libere, di punto in bianco possano non esserlo più (ma nessun esempio viene fatto in merito); fortunatamente, aggiungo io, Java è ora sotto GPL, il che non è male, senza contare il fatto che gli autori sembrano a tratti sottovalutare il potere del Free Software, che invece io ritengo discretamente rilevante.
• La modularizzazione che verrà introdotta con Java 7 (hopefully, aggiungo io) non sembra riscontrare i favori della tavola rotonda, in particolare si criticano gli approcci, forse troppo teorici o comunque troppo lontani dalla realtà.
• Non mi soffermo sul problema di “Java è morto”: premesso che lo si dice da anni (e non succede, per ora), il fatto che la Virtual Machine supporti molti altri approcci diversi (funzionali piuttosto che “a la Rails“) fa supporre che il “mondo Java” non sia così facilmente abbattibile.
• Il cloud computing (parafrasando gli Iron Maiden: “Cloud, cloud everywhere / Cloud, cloud everywhere“): per quanto tutti ritengano il cloud soprattutto una buzzword del momento, l’idea è che le tecnologie sottostanti restino interessanti, ed in particolare l’acquisizione di SpringSource da parte di VMWare fa pensare ad uno sviluppo in quella direzione del famoso framework Spring.
• Java nelle nuove industrie: tolto il discorso cloud, il discorso mobile (Android in particolare) è assolutamente interessante, sottostando tuttavia alla risoluzione positiva della modularizzazione, ed al contempo all’affrontare e risolvere in maniera decente Java ed il multimedia (da sempre tallone d’Achille, per usare un eufemismo).

Da notare, a margine, come il campo dell’informatizzazione nel no-profit sia ritenuto assolutamente redditizio e colonizzabile, ed è interessante dato che è un discorso emerso anche tra di noi in altre sedi e con altre persone.

Java 7

Il secondo articolo si concentra invece sulle innovazioni che Java 7 (previsto entro l’anno) dovrebbe portare con sè; integro i punti seguenti anche con un paio di riflessioni del primo articolo (per evitare di ripetere le cose due volte), sottolineando come ho ignorato la seconda parte di questo articolo, dato che si parla della VM di IBM, che io non uso (e che peraltro credo sia a pagamento):

• semplificazione della scrittura di linguaggi “di scripting” sulla JVM: ne avevo già sentito parlare l’anno scorso, dato che avevo fatto una ricerca in merito per l’articolo del corso di “Argomenti avanzati di Ingegneria del Software” (e, se vi interessa, leggetevi l’articolo tra le mie pubblicazioni), e di fatto sono introdotte cose (che io non voglio sapere…) per rendere semplice la resa di linguaggi dinamici in bytecode, velocizzandone anche le prestazioni.
• Le stringhe nei costrutti switch: sono quasi commosso, dato che è una cosa di una utilità tremenda, che ho sempre invidiato a PHP.
• Le chiusure: alcuni autori nella tavola rotonda sottolineavano come la popolarità di linguaggi su JVM come Groovy indichi che il popolo richiede a gran voce le chiusure, e queste atterreranno nei nostri computer molto presto; la sintassi definitiva è ancora in fase di sistemazione, ma restano sicuramente interessanti soprattutto per la dinamicità del codice che risulta.
• La concorrenza tra processi e thread: mi viene di nuovo in mente Erlang, quando viene citato il framework Kilim (con cui devo assolutamente curiosare) ed il paradigma fork-join che verrà portato con Java 7, che di fatto è l’idea che sta dietro anche all’algoritmo di map-reduce; l’applicazione forzata del buon vecchio Divide et impera non può che essere importante all’alba dei multicore.

In conclusione (mia, non degli articoli)

Insomma, tirate le fila di queste riflessioni, direi che di carne al fuoco ce n’è parecchia ancora: sono sinceramente curioso di provare qualcuno dei linguaggi costruiti sulla JVM (ad esempio Scala, cui avevo assistito ad una presentazione lo scorso JavaDay), e di vedere come sarà la versione finale delle closure (dato che, ormai, con il mio lavoro di tesi su Erlang ne uso a palate); non credo che Java sia morto, o quantomeno non credo che morirà senza combattere.

Read Full Post »