Timeline for Just a lowly counter that turned out to be surprisingly complicated
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 5, 2015 at 9:54 | vote | accept | 200_success | ||
| May 31, 2014 at 15:35 | comment | added | bowmore |
@skiwi : I have updated the answer. I had only learnt about the new LongAdder class after I've submitted this answer, and I hadn't gone back to it since. Thanks for pointing out the possible improvement.
|
|
| May 31, 2014 at 15:32 | history | edited | bowmore | CC BY-SA 3.0 |
added 288 characters in body
|
| May 30, 2014 at 18:09 | comment | added | skiwi |
Since you are suggesting Java 8 either way (which is great!), I'd urge you to also incorporate LongAdder in the answer. It's essentially the new AtomicInteger when you are only adding and retrieving.
|
|
| Mar 19, 2014 at 20:01 | comment | added | 200_success |
TreeMap wouldn't be able to work with DESC_FREQ_COMPARATOR, then.
|
|
| Mar 19, 2014 at 19:47 | history | edited | Jamal | CC BY-SA 3.0 |
Clearer formatting
|
| Mar 19, 2014 at 19:46 | comment | added | bowmore | You're obligated to implement equals(Object), but only if you implement the Map interface. Personally I wouldn't bother about equality. | |
| Mar 19, 2014 at 19:45 | comment | added | bowmore | TreeMap is sorted by keys, not by values. If you introduce the Count interface I suggested, you can make that Comparable, and you can simply sort those, or use max()/min() | |
| Mar 19, 2014 at 19:43 | history | edited | bowmore | CC BY-SA 3.0 |
added 427 characters in body
|
| Mar 19, 2014 at 19:42 | comment | added | 200_success |
I believe I'm obligated to implement .equals(Object other) rather than .equals(Counter<T> other)?
|
|
| Mar 19, 2014 at 19:40 | comment | added | 200_success |
The TreeMap would not rearrange itself when the AtomicInteger mutates, would it?
|
|
| Mar 19, 2014 at 19:34 | history | answered | bowmore | CC BY-SA 3.0 |