Sunt multe "lucrușoare" din Java pe care chiar și cei care programează zilnic în Java nu le (mai) știu și mai ales pentru că nu le folosesc. Pentru asta există cărțile de Java, să ne mai aducă aminte de multe astfel de secrete. Recunosc, spre rușinea mea, că nu am folosit până în prezent prea mult (în mod voit) avantajele polimorfismului, cel puțin în cazul apelurilor de metode.

Și astfel ajungem la subiect. Eu nu știam sau nu mi-am pus niciodată problema că ceea ce pot face astfel cu vectori:

public class PoliArrayExample {
    public static void main(String[] args) {
        Integer[] ints = new Integer[3];
        Arrays arrs = new Arrays();
        arrs.doSomethingWithArrays(ints);
    }
}

class Arrays {
    public void doSomethingWithArrays(Object[] arr) {
        arr[0] = new String("test");
    }
}

cu colecții nu este posibil, mai exact acest lucru nu se poate face:

public class PoliArrayExample {
    public static void main(String[] args) {
        ArrayList<Integer> ints = new ArrayList<Integer>();
        Arrays arrs = new Arrays();
        arrs.doSomethingWithArrays(ints);
    }
}

class Arrays {
    public void doSomethingWithArrays(ArrayList<Object> arr) {
        arr.add("");
    }
}

Se pare că în cazul colecțiilor în momentul în care semnătura metodei public void doSomethingWithArrays(ArrayList<Object> arr) va arăta astfel, nu vom putea apela decât cu un ArrayList de tip Object, fără subclase sau superclase (nu că Object ar avea super clase, dar putem extrapola). Prin urmare, în codul anterior vom avea probleme la linia 5. Acest lucru poate fi oarecum păcălit:

public class PoliArrayExample {
    public static void main(String[] args) {
        ArrayList<Integer> ints = new ArrayList<Integer>();
        Arrays arrs = new Arrays();
        arrs.doSomethingWithArrays(ints);
    }
}

class Arrays {
    public void doSomethingWithArrays(ArrayList<? extends Object> arr) {
        arr.add("");
    }
}

spunându-i compilatorului să accepte și clase care au extins sau implementat clasa/interfața de după extends, cu condiția să nu adăugam nimic în colecția primită ca și parametru. Astfel, nu scăpăm, primind o eroare de compilare la linia 11, spunându-ne că nu există metoda add cu parametru de tip String. Putem folosi șmecheria de mai sus, atât timp cât nu adăugăm în acea colecție nimic. Și așa cum cu extends am permis accesul subclaselor, cu super putem permite accesul superclaselor:

public class PoliArrayExample {
    public static void main(String[] args) {
        ArrayList<Object> ints = new ArrayList<Object>();
        Arrays arrs = new Arrays();
        arrs.doSomethingWithArrays(ints);        
    }
}

class Arrays {
    public void doSomethingWithArrays(ArrayList<? super Integer> arr) {
        arr.add(new Integer(1));
    }
}

Și în acest caz nu vom avea nicio problemă să și adăugăm elemente în colecție, atât timp cât sunt de tipul specificat sau subclase ale tipului specificat. (mulțumesc Ducu pentru corectură!)

Toate acestea se întâmplă datorită modului în care au fost implementate genericele în Java. Cei care au făcut genericele în Java au dorit ca odată cu apariția genericelor să poată fi folosit și codul de dinainte de Java 5 și generice. Prin urmare, genericele sunt doar la nivel de compilator și la runtime un obiect de tip List<String> devine un simplu obiect List și Java nu mai are niciun control asupra ceea ce pui în lista respectivă. La vectori treaba stă altfel și un String[] chiar și la runtime tot String[] rămâne și când vom încerca să adăugăm altceva decât tipul permis vom primi o excepție (ArrayStoreException).

În questul iniţiatic de pregătire pentru susţinerea examenului de certificare SCJP 6, am întâłnit tot felul de noţiuni pe care nu le ştiam/foloseam, unele utile, altele nu (din punctul meu de vedere) şi am zis să le înşir undeva în funcţie de cum am chef să fac asta! Şi ce loc mai bun decât blogul personal? Iată o serie din ele:

• metoda Object.finalize() marchează obiectul că-l poate lua garbage collectorul, când va crede de cuviinţă Măria sa! Evident este o metodă de instanţă, am expus-o astfel pentru a fi mai scurt in exprimare;
• diferenţa dintre StringBuilder şi StringBuffer este că StringBuffer este thread-safe, adică are metodele synchronized şi din cauza asta metodele lui vor rula mai greu, deci dacă nu aveţi o aplicaţie multi-thread, folosiţi StringBuilder;
• putem folosi clasa Scanner pentru a face nişte splituri ceva mai şmechere. Clasa are ca separator implicit spaţiu "  " şi cu ajutorul metodelor nextXxx() putem sări la următorul token de tipul Xxx (prin token se înţelege informaţia utilă splituită de separator);
• dacă încercăm să compilăm un cod în care serializăm o clasă care nu a implementat interfaţa Serializable sau are un atribut care nu este primitivă şi nu a implementat interfaţa Serializable, ne vom trezi cu excepţie;
• dacă încercăm să serializăm o clasă care implementează interfaţa Serializable dar extinde o clasă neserializabilă, la deserializarea clasei se va apela constructorul super clasei extinsă de clasa serializată;
• putem folosi modificatorul transient pentru a marca o variabilă să nu fie serializată; la deserializare ea va fi iniţializată cu valoarea implicită pentru acel tip;
• există interfeţe "marker", adică nu au niciun fel de metode; acestea sunt folosite ca nişte etichete aplicate clasei ce le implementează, pentru a scoate în evidenţă nişte capacităţi ale acelei clase;

Vor mai urma...

Cei care ați făcut C sau C++ vă aduceți aminte de așa numitele transmiteri de parametri prin valoare sau prin referință. În Java nu există ‘sau’ ci doar call-by-value, indiferent de tipul parametrului.

În momentul în care apelăm o metodă cu parametrii primitivi atunci valoarea lor este transmisă parametrilor formali din metodă. În cazul unor obiecte, valoarea referință este transmisă parametrilor formali și nu obiectul cu totul. Ceea ce înseamnă că și parametrul formal, dar și parametrul inițial din apel vor referenția același obiect din memorie. Acest lucru are cel puțin două consecințe:

1. Orice modificări făcute asupra stării obiectului referențiat de către parametrul formal, vor fi vizibile și după încheierea apelului metodei;
2. Dacă modificăm parametrul formal din metodă(deci nu starea obiectului referențiat de el), modificarea nu va fi vizibilă după ieșirea din apel.

   1: public class Test {

   2:     public String rezultat = "bun";

   3:     public Test() {

   4:         System.out.println("Constructor din Test");

   5:     }

   6:     

   7:     public void schimba(Test tst) {

   8:         tst.rezultat = "rau";

   9:         tst = null;

  10:     }

  11:     

  12:     public static void main(String[] args) {

  13:         Test tst = new Test();

  14:         System.out.println(tst.rezultat);

  15:         tst.schimba(tst);

  16:         System.out.println(tst.rezultat);

  17:     }

  18: }

După compilare și rulare, acest program va afișa:

Constructor din Test

bun

rau

La linia 8 se modifică starea obiectului Test referențiat de parametrul formal tst, iar la linia 9 se asociază lui tst valoarea null. Modificarea asupra atributului rezultat se poate observa la ieșirea din apelul metodei schimbă.

Începând cu Java 1.5 a fost introdusă facilitatea de a creea metode cu număr de parametrii variabil. Astfel de metode sunt numite metode cu aritate variabilă și pot permite apeluri cu un număr mai mare de parametri decât parametrii formali din semnătura metodei.

Pentru o metodă cu aritate variabilă, ultimul parametru formal trebuie declarat în felul următor:

<tip>… <nume parametru formal>

Prin urmare, în semnătura unei metode cu aritate variabilă putem avea un singur parametru formal ca mai sus și acesta trebuie să fie ultimul în lista de parametri formali. De asemenea, o altă consecință este că parametrii care pot varia ca număr sunt de același tip.

Parametrul formal ce variază este, de fapt, un array care este umplut cu parametrii dați în plus la apel. Prin urmare, următoarele semnături ale metodei angajare sunt considerate identice:

public void angajare(String… candidati);

public void angajare(String[] candidati);

Dacă cele două semnături sunt considerate identice, în momentul în care am încerca să facem overload la prima formă cu a doua(sau invers), am primi eroare la compilare.

După cum bine se știe un Array, în Java, se poate declara în felul următor:

int[] numere[] = new int[10][10];

Parantezele pătrate se pot pune ori la tipul de date, ori la numele variabilei, ori la amândouă. De asemenea dimensiunea poate lipsi la ultimele dimensiuni ale array-ului. Deci aș fi putut scrie și așa:

int[] numere[] = new int[10][];

Există două modalități de a face declararea și inițializarea unui Array:

1. int[] numere = new int[] {1, 2, 3, 4};
   Atenție: cand se face inițializarea array-ului nu se mai trece dimensiunea!
2. int[] numere = {1, 2, 3, 4};
   Acesta este un bloc de inițializare, care poate fi folosit în locul liniei de mai sus, are același efect.

Diferența între cele două modalități este că cea de-a doua nu este o expresie și nu poate fi folosită în felul următor:

int[] numere;

numere = {1, 2, 3, 4}; //nu e ok

numere = new int[] {1, 2, 3, 4}; //e ok

Câte ceva despre tipul Enum:

• un tip care conține un set de constante;
• un tip enum poate avea constructori, dar aceștia trebuie declarați după definirea constantelor și pot fi doar private;
• toate enum-urile sunt subtipuri ale clasei java.lang.Enum, prin urmare sunt comparabile și serializabile;
• la definirea constantelor se poate specifica o listă de parametri pentru fiecare, iar la încărcarea enum-ului pentru fiecare constantă se va apela constructorul corespunzător semnăturii ei;
• un enum poate fi declarat în cadrul unei alte clase, dar doar ca membru de prim nivel sau în cadrul unui membru static; toate enum-urile declarate în cadrul unei alte clase sunt implicit statice;
• deși un enum poate coține diferite metode abstracte, tipul nu va fi marcat ca și abstract, ca în cazul claselor obișnuite;
• fiecare constantă a unui enum poate implementa diferite metode specifice, sub forma unor clase anonime care sunt instanțiate la “runtime”;
• un enum poate implementa interfețe dar nu poate extinde;
• Compararea cu == sau cu equals este echivalentă în cazul constantelor unui enum;

*Conform Java 1.6