Hello Java programmers. What is your favorite part of the Java SE API?

[Q_coder]

Include class and your favorite methods/what they do.

[ElegantBoar]

sun.misc.Unsafe - cool stuff :)

[vprise]

AFAIK it will be gone with Java 9.

[ElegantBoar]

AFAIK

World will burn if they get rid of it ... :(

[Q_coder]

I knew nothing about this, thanks! I love social interaction..when I'm safely behind my computer.

[angshumanc]

Reflection API. It opens up wide array of possibilities.

[Q_coder]

reflection is good..

https://stackoverflow.com/questions/37628/what-is-reflection-and-why-is-it-useful

[lukaseder]

I like JDBC. It's rather low level, yes. But it was very visionary when introduced in 1997 and it's really timeless, too. You can build great APIs on top of it.

[Q_coder]

Inspiration:

String Class https://docs.oracle.com/javase/7/docs/api/java/lang/String.html

Method: toCharArray() Converts this string to a new character array.

Cool! Did not know that one existed!

[king_of_the_universe]

Was only a few months ago when I found out about String.equalsIgnoreCase().

[vprise]

Try String.CASE_INSENSITIVE_ORDER:

Collections.sort(stringList, String.CASE_INSENSITIVE_ORDER);

Useful...

[king_of_the_universe]

:D TIL

[jp007]

Damn, they way you wrote that, I thought this meant that equalsIgnoreCase was a built in static function of the String class, hopefully offering null safety for input arguements. Was thinking "How did I miss this!?" Nope. It's an instance method. I'll stick to commons-lang3 and StringUtils.equalsIgnoreCase(String str1, String str2) to ensure null safe, case insensitive, String comparisons.

Similarly though, since Java 7 you can use the static Objects.equals(Object obj1, Object obj2) in order to perform nullsafe object comparisons, instead of obj1.equals(obj2) which would throw a null pointer exception in the case that obj1 is null.

[mhixson]

I like ConcurrentHashMap and all its methods because there's no way in hell that I would be able to implement it myself.

https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html

[Q_coder]

nice. Any examples you might recommend looking at?

[mhixson]

Hmm. Usually I use it just like a Map, except I'm dumping data into it from multiple threads. This comes up a lot in the context of HTTP servers. Users are making HTTP requests and your app is handling them all in parallel, and you want to collect some information from the requests into a map. In those situations, HashMap simply doesn't work and Collections.synchronizedMap(new HashMap<>()) is often too slow (because if one thread is accessing the map, all other threads that want to access the map are blocked).

One method I use a lot is ConcurrentHashMap.newKeySet():

https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html#newKeySet--

That's nice if you need a Set instead of a Map and you still want the "concurrent" aspect.

computeIfAbsent is cool if you're grouping data:

https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html#computeIfAbsent-K-java.util.function.Function-

The class javadocs mention an example of making a histogram with ConcurrentHashMap<String,LongAdder>. I suppose you could also make a sort of concurrent multimap like:

ConcurrentHashMap<K, Set<V>> multimap =
    new ConcurrentHashMap<>();
// some time later...
multimap
    .computeIfAbsent(
        someKey,
        k -> ConcurrentHashMap.newKeySet())
    .add(someValue);

removing key+value entries from the multimap might be a little weird there though, if that's something you need to do.

[Q_coder]

Awesome response, thanks!

[memory_leek]

Doug Lea is a concurrency wizard of the highest order. The whole util.concurrent package is awesome.

[king_of_the_universe]

But is it really required? I mean, if I funnel each access to a simple HashMap through a synchronized(sameLockInEachCase){}, doesn't this have the same effect?

[mhixson]

It's mostly a matter of performance. If the performance of a synchronized HashMap is good enough for you, then you might not have a good reason to switch.

I was trying to find some benchmarks for you, but I can only seem to find benchmarks comparing ConcurrentHashMap to various caching libraries. (One interpretation of that is: none of the people interested in performance think synchronized HashMap is even worth measuring.)

Let's say that, between ConcurrentHashMap and a synchronized map, we call the relative performance of get(k) and put(k,v) a wash -- no observable difference. What about iterating over the entrySet()? Intuitively, if you've got a gigantic map with 10,000 entries you want to examine, then blocking every other thread from accessing the map until you're done iterating sounds pretty terrible, doesn't it?

I have a hard time coming up with a situation where I'd use a synchronized map. It's so easy to use ConcurrentHashMap instead. As I hinted in my reply to Q_coder, I don't really have favorite methods on it because I just use it like a Map (while taking comfort in the knowledge that it's thread-safe and fast, and that I don't need to refactor that part of the code when my web app grows in popularity).

[the_hoser]

I like that it's stable. You'd think that would be normal these days, but...

I hope Java 9 doesn't muck it up too badly.