Overloading del costruttore – REVIEWED -

Eh sì, devo proprio dirlo. Ho sbagliato !!! Non che non mi capiti mai, ma questa volta l’ho anche scritto sul mio blog, quindi DEVO riparare e salvare quello che ancora rimane della mia reputazione. L’errore è stato nel post in cui si parlava dell’overloading del costruttore, rimetto di seguito il giochino che avevo pubblicato:

1
2
3
4
5
6
7
8

public class OverloadResolver {
    public OverloadResolver(Object param) {
        System.out.println("Construttore con parametro Object");
    }
    public OverloadResolver(Object[] param) {
        System.out.println("Costruttore con parametro Object[]");
    }
}

La domanda era: "Qualcuno sa cosa succede se faccio questa chiamata:"

1
2
3
4
5

......
public static void main(String[] args) {
    OverloadResolver or = new OverloadResolver(null);
}
......

Ingenuamente mi son fidato. Nel senso che ho considerato buona la risposta che ho trovato nell’articolo che ho letto in internet, (in realtà volevo anche rispondere ora che so la risposta corretta, ma non riesco più a trovarlo, poi vi dico se lo trovo) e quindi non mi sono posto il problema di testarlo. Quando ieri, un caro vecchio amico, mi ha fatto gentilmente notare, e per gentilmente intendo a modo suo, che la risposta da me data non era quella giusta, in quanto diffidando dalla risposta ha testato l’esempio, e il risultato non era quello che avevo dato. Quindi, eseguendo l’esempio, il risultato è che viene richiamata la funzione:

1
2
3

public OverloadResolver(Object[] param) {
    System.out.println("Costruttore con parametro Object[]");
}

Perchè ? Il motivo lo incollo, così come l’ho trovato in internet, ovviamente sul sito della sun:

So the third rule is to choose the most "specific" method. The rule is: if any method still under consideration has parameter types that are assignable to another method that’s also still in play, then the other method is removed from consideration. This process is repeated until no other method can be eliminated. If the result is a single "most specific" method, then that method is called. If there’s more than one method left, the call is ambiguous. Suppose that you have the methods: f(float) f(double) In this case, the parameter types for the first method are assignable to the parameter types of the second method, that is, it’s legal to say: double = float through a widening primitive conversion. By contrast, saying: float = double is not valid without a cast. Based on this third rule, f(double) is removed from the set of possible methods to call, and therefore f(float) is called.

Morale della favola? La prossima volta non fidatevi degli articoli trovati in rete senza prima averli provato. Ciauu

Overloading del costruttore

1
2
3
4
5
6
7
8

public class OverloadResolver {
public OverloadResolver(Object param) {
System.out.println("Construttore con parametro Object");
}
public OverloadResolver(Object[] param) {
System.out.println("Costruttore con parametro Object[]");
}
}

Qualcuno sa cosa succede se faccio questa chiamata:

1
2
3
4
5

......
public static void main(String[] args) {
OverloadResolver or = new OverloadResolver(null);
}
......

Cioè se richiamo quel costruttore con parametro null, cosa viene richiamato nella classe di sopra ? Dai dai dai che lo sapete……e ditelo !!!!!! (magari qualcuno commenterà….chi lo sa!!!)

Java FX

Sono vivo, sono vivo..sono sparito solo x un pò di tempo causa GROSSI impegni di lavoro….ma siamo quasi alla fine…siamo allo sprint finale, e poi ….? E poi cosa !?!? Ancora dell’altro lavoro, ovviamente…si sgobba alla grande. Durante la conferenza JavaOne di San Francisco, Sun Microsystems ha annunciato un nuovo ambiente di scripting Java e una nuova piattaforma di strumenti e software, dedicati allo sviluppo di Rich Internet application (RIA) per un ampio utilizzo, dai cellulari al desktop. La nuova suite di prodotti si chiama JavaFX. Java FX Script è un linguaggio di scripting che permette lo sviluppo di interfacce grafiche avanzate, mentre Java FX Mobile è un ambiente operativo per lo sviluppo di applicazione per sistemi mobile costruito intorno a Linux e Java. Java FX utilizza una sintassi dichiarativa per lo sviluppo dei componenti grafici, in questo modo la specifica del codice corrisponde esattamente in modo conciso con il layout della GUI. Il linguaggio fa uso in modo intensivo di Java2D swing per lo sviluppo dei componenti grafici. Il nuovo linguaggio sviluppato da Sun mira dunque a conquistare il terreno di AJAX e Flash, permettendo con maggiore facilità la creazione di applicazioni per la rete e, nella sua variante mobile, per i dispositivi mobili, con l’immediato beneficio di poter essere eseguito da subito dalla moltitudine di piattaforme già pronte (ma si parla solo di pc, per i cellulari sarà indispensabile installare il software apposito). Al momento JavaFX è stato distribuito in versione alpha e per il futuro è già pianificata l’introduzione di strumenti per il controllo, widgets ed altri tool. Ma vediamo un esempio di come è fatto un semplice programma che crea un componente grafico ….molto molto semplice.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

import javax.swing.JFrame;
import javax.swing.JButton;
import java.awt.event.ActionListener;
import java.lang.System;
/* Code */
var frame = new JFrame();
var button = new JButton("Press me");
    frame.getContentPane().add(button);
    button.addActionListener(new ActionListener() {
        operation actionPerformed(event) {
        System.out.println("You pressed me");
    }
});
frame.pack();
frame.setVisible(true);

Come si può vedere il codice importa classi Java, crea oggetti, richiama dei metodi e implementa delle interfacce. Non è necessario creare classi in modo formale così come lo impone lo standard di sviluppo delle classi. Eseguendo il codice di sopra, quello che si ottiene è il risultato della figura seguente:

Un modo analogo più conciso e preferibile per lo sviluppo della stessa interfaccia di sopra è il seguente:

1
2
3
4
5
6
7
8
9

Frame { 
    content: Button { 
    text: "Press Me"
    action: operation() {
        System.out.println("You pressed me");
    }
}
visible: true 
}

diciamo che questo caso è più JavaFX. Questo è quanto volevo raccontare, diciamo che con la versione alpha non so a che livello di affidabilità è JavaFX (che per inciso si pronuncia Java eff-ect-s), a quanto se ne parla si possono fare veramente i numeri con le interfacce grafiche, scrivendo pochissimo codice…ovviamente data la natura di Java, questo può essere eseguito su molte piattaforme. Vi rimando ai siti della SUN per farvi un idea più approfondita e per vedere nel dettaglio le specifiche del linguaggio. Ci sono anche degli altri esempi con demo molto interessanti.

l’avreste mai detto che…

Salve, eccomi qui… non credo che abbia molto pubblico, e chissà quando mi troverete nell’infinito di Internet, ci saranno milioni di blog sulla programmazione, quindi passerà un bel po di tempo prima che mi scoviate…spero nella bontà di gooogle che possa indicizzarmi presto come si deve. Nell’attesa volevo parlare di una cosa che ho letto poco tempo fa, che mi ha fatto notare ancora una volta quanto è potente Java. Vi sottopongo la seguente domanda: "Quale linguaggio di programmazione tra C++ e Java risulta più veloce nell’allocazione della memoria?". Non ci crederete ma la risposta è Java !!! Nelle moderne JVM l’allocazione della memoria risulta essere molto veloce rispetto alle classiche operazioni di malloc() usate in C++. Più precisamente in Java sono richieste 10 istruzioni macchina (approssimativamente) per allocare memoria per la più comune delle allocazioni
new Object() mentre in C++ sono richieste una media di 60-100 istruzioni macchina. Ovviamente non c’è trucco non c’è inganno, nel senso che quelle ottime performance si devono alla gestione della memoria da parte della JVM. La JVM utilizza un garbage collector generazionale, cioè la memoria (l’heap) viene suddiviso in spazi generazionale, uno detto young e l’altro old. In questi due spazi vengono mantenuti i riferimenti agli oggetti presenti nella memoria la cui vita risulta essere rispettivamente corta o lunga, misurata in operazioni di garbage collector. Più precisamente gli oggetti che hanno superato un certo periodo di tempo vengono trasferiti dallo spazio young a quello old e vengono etichettati come long lived. Ad ogni operazioni del garbage collector gli oggetti più vecchi vengono eliminati dalla memoria e quindi viene liberato lo spazio per i nuovi. Sebbene questo è il funzionamento di base della gestione della memoria di Java, la pratica è leggermente diversa, la JVM offre 3 young-generational collectors, che sono serial copying, parallel copying, e parallel scavenge. Tutti e tre hanno la caratteristica di dividere lo spazio di memoria a metà e utilizzano sempre una metà alla volta fino a che non viene riempita. L’allocatore della memoria soddisfa le richieste di allocazione restituendo i primi N bytes della portione di memoria libera, spostando un puntatore che separa le due parti "utilizzata" da "libera". In definitiva, l’allocazione di memoria consiste nel controllare se esiste dello spazio disponibile nell’heap e restituire un puntatore ad esso, senza effettuare alcuna ricerca o adottare alcuna politica di gestione dello spazio. C++ offre al programmatore la scelta di adottare l’allocazione di memoria sia sullo heap che sullo stack. Il fatto di utilizzare lo stack per allocare la memoria implica un aumento delle prestazioni, sia durante l’allocazione che è economica in termini prestazionali e sia durante la deallocazione che costa 0, inoltre i linguaggi implementano una attenta gestione della politica di demarcazione degli oggetti, riducendo così il rischio di non liberare lo spazio al termine della vita di un oggetto. Un altro vantaggio dello stack è dato dal fatto di essere molto più cache-friendly, e questo indica un aumento delle prestazioni in termini di diminuzione dei cache miss, per i quali, sui moderni processori, si hanno dei ritardi significativi. Java non consente al programmatore di allocare spazio direttamente sullo stack, ma questo non è un grosso vincolo, dal momento che la JVM va ad allocare all’occorrenza spazio sullo stack che permette così di aumentare di molto le prestazioni. Le JVMs utilizzano una tecnica chiamata escape analysis la quale permette di stabilire che alcuni oggetti per tutta la durata del loro lifetime, rimarranno confinati all’interno di un singolo thread e pemette di mappare questo lifetime con il lifetime di uno stack-frame. Queste valutazioni permettono l’allocazione di questi oggetti direttamente sullo stack piuttosto che sullo heap, e addirittura per piccoli oggetti la JVM può richiedere l’allocazione direttamente sui registri, aumentando ancor di più le prestazioni. Tutto questo lungo discorso fa intuire quanto l’ottimizzazione da parte della JVM conti e quanto può essere determinante in termini di prestazioni, ovviamente anche il fatto che Java non ha compilati ma byte-coded conta molto. La fonte di questo articolo è IBM se volete approfondire vi consiglio di seguire il link.