Názory k článku Novinky v JDK 7 (5) – projekt Lambda a anonymní funkce v příkladech

Trochu mě zarazilo, proč musí být při použití Arrays.sort překryta metoda equals tak, aby vracela true pro compareTo(...) == 0. Pokud vím, compareTo je součástí interfacu Comparable a tedy při použití komparátoru toto nepoužiji. Nebo se mýlím? Předpokládám, že v komparátoru, který funkci Arrays.sort předávám, nepotřebuji metodu compareTo nebo equals. Od toho tuším komparátor je.

Přiznámvám se ale, že v Javě natolik zběhlý nejsem, proto pokud je tam nějaký důvod, který nevidím, budu rád, když se jej dovím.

Mate pravdu, v textu ma byt compare() nikoli compareTo(), omlouvam se za zmateni.

Pri pouziti Arrays.sort() NEMUSI byt equals() prekryta, a to ani pri pouziti komparatoru ani v pripade, ze trida, jejiz instance se radi, implementuje rozhrani Comparable a tedy i metodu compareTo().

Konkretne zde je implementace Arrays.sort() zavolana v pripade, ze se teto metode preda krome pole i komparator. Zadne equals() se zde nevola, pouze compare():

private static void mergeSort(Object[] src,
                              Object[] dest,
                              int low, int high, int off,
                              Comparator c) {
    int length = high - low;

    // Insertion sort on smallest arrays
    if (length < INSERTIONSORT_THRESHOLD) {
        for (int i=low; i<high; i++)
            for (int j=i; j>low && c.compare(dest[j-1], dest[j])>0; j--)
                swap(dest, j, j-1);
        return;
    }

    // Recursively sort halves of dest into src
    int destLow  = low;
    int destHigh = high;
    low  += off;
    high += off;
    int mid = (low + high) >>> 1;
    mergeSort(dest, src, low, mid, -off, c);
    mergeSort(dest, src, mid, high, -off, c);

    // If list is already sorted, just copy from src to dest.  This is an
    // optimization that results in faster sorts for nearly ordered lists.
    if (c.compare(src[mid-1], src[mid]) <= 0) {
       System.arraycopy(src, low, dest, destLow, length);
       return;
    }

    // Merge sorted halves (now in src) into dest
    for(int i = destLow, p = low, q = mid; i < destHigh; i++) {
        if (q >= high || p < mid && c.compare(src[p], src[q]) <= 0)
            dest[i] = src[p++];
        else
            dest[i] = src[q++];
    }
}

Tu si to autor mohol dovolit. Teda ak predpokladame, ze ani vek ani plat nemoze byt zaporny. Ak by ale mohol, pri odcitavani moze dojst k preteceniu. Kto neveri nech vyskusa toto:

public static void main(String[] args) {
int i1 = Integer.MIN_VALUE;
int i2 = 1;
System.out.prin­tln(i1 - i2); // tu by compare vratilo nespravny vysledok!
System.out.prin­tln((long) i1 - (long) i2);
}

Je to tak, v realne aplikaci by se urcite musely dat kontroly v tomto pripade do konstruktoru. Pravdepodobne nejenom pro zaporna cisla, ale i pro nejaky vhodny rozsah veku a platu.

Ale je urcite dobre, ze jste na to upozornil, pokud kontroly pro hodnoty atributu chybi, je zadelano na problem.

Pokud se pouze pretizi equals(), tak to pracovat bude, protoze se pri pristupu k prvkum nejdrive kontroluje hashCode(), ktery musi byt shodny soucasne s equals(). I kdyz se samozrejme jedna o krehky kod, ktery zavisi na tom, ze hashCode() pro kazda dve sestimistna cisla je rozdilny - coz je, ale pro jine JDK to nemusi platit ;-)

Kdyz uz jsme u JCP, tady je jedna cerstva zpravicka https://blogs.apache.org/foundation/entry/the_asf_resigns_from_the

Apache foundation melo dost dobre napady, jakym smerem Javu rozsirovat, tak uvidime, co udelaji dale.