manu2794 ha scritto:
Al comparator dovrei passare l'intera mappa? Cosi facendo avrei un compare con due mappe come parametri
No, detto così è sbagliato. Il compare() di Comparator, nel contesto delle sorted-map, riceve sempre e solo due CHIAVI.
Comunque ci ho ragionato un po' e .... non è così banale. Partiamo dal punto semplice: quando devi conteggiare le occorrenze delle coordinate, ti conviene usare HashMap come detto prima. Quando hai finito questo step, qui viene la parte difficile.
Il comparator va passato ad un costruttore di TreeMap. Non c'è altro modo, perché il criterio di comparazione non può cambiare in TreeMap successivamente.
Il comparator NON può accedere al TreeMap stesso. Non perché non sia possibile tecnicamente (si fa) ma perché il comparator viene invocato ad ogni operazione di ricerca all'interno del TreeMap, anche quando si inserisce qualcosa. Se all'interno del comparator fai un get sulla stessa mappa, scateni altre ricerche che invocano di nuovo il comparator ecc... Morale: "esplode" tutto con un bel StackOverflowError.
Il comparator potrebbe accedere al HashMap della prima fase. Questo sì, tecnicamente è possibile e non darebbe problemi.
Il punto è che alla fine, ammesso di arrivare a popolare il TreeMap, avresti questo TreeMap il cui Comparator si basa su un'altra mappa, il HashMap. Quindi avresti sì l'ordinamento per valore (le occorrenze) e la iterazione darebbe quel ordine. Ma non ci potresti fare altro.
Pertanto: alla luce di questo, ti è chiaro? Cosa pensi di fare? Sicuro che serva davvero un SortedMap<Coordinate,Integer> con criterio "per valore"?? E magari non si possa fare in altro modo?