4 Out of 5 Java Developers Failed to Solve This Problem

a few months ago we released a new side project of ours with a minisite called java deathmatch (a puzzle minigame for developers), and since then over 20,000 developers have given it a try. the site features 20 multiple-choice java questions and today after we’ve gathered stats from all the games that have been played we’re happy to share some of the results and solutions with you.

overall we collected 61,872 answers, which gives us about 3,094 answers for each of the 20 questions. each java deathmatch session randomly chooses 5 questions and gives you 90 seconds to solve each one. every question has 4 possible answers. we’ve been criticized that the questions are too hard but, well, it’s not called a deathmatch for no reason! using those stats, we were able to determine which were the hardest questions, and which were the easiest. in this post we’d like to share the 5 toughest questions from this experiment and solve them together.

new post: 4 out of 5 #java developers failed to solve this question http://t.co/b9m6b9nfhm pic.twitter.com/2qmnhcqlro

— takipi (@takipid) july 27, 2015

on average, 41% of attempted answers were correct, which is not bad at all. the live stats of the results and questions by index are available right here . the stats for this post are a snapshot from july 26th. check out java deathmatch for the full quiz.

1. the toughest question of the java deathmatch

let’s start with the toughest nut to crack, a question we received from alexandru-constantin bledea from bucharest. and it’s a real brain teaser. only 20% of the participants were able to solve this questions. this means if you would have chosen an answer at random – you’d probably have a better chance at hitting the right one. java generics have this quality about them.

alright, so what do we have here? we have generics with type erasure involved, and a couple of exceptions. a few things to remember here:

1. runtimeexception and sqlexception both inherit from exception, while runtimeexception is unchecked and sqlexception is a checked exception.
2. java generics are not reified, meaning that in compile time, the generic type information is “lost” and treated as if the code is replaced with the type’s bound or with object if it doesn’t exist. this is what you call type erasure.

naively we’d expect line 7 to cause a compilation error since you can’t cast sqlexception to runtimeexception, but that’s not the case. what happens is that t is replaced with exception so we have:

throw (exception) t;  // t is also an exception

since pleasethrow expects an exception , and t is replaced with exception , the cast is eliminated as if it wasn’t written. we can see that in bytecode:

private pleasethrow(ljava/lang/exception;)v throws java/lang/exception
l0
linenumber 8 l0
aload 1
athrow
l1
localvariable this ltemp; l0 l1 0
// signature ltemp<tt;>;
// declaration: temp<t>
localvariable t ljava/lang/exception; l0 l1 1
maxstack = 1
maxlocals = 2

just for fun, we tried to see what the bytecode will look like without generics involved, and the cast appeared right before the athrow statement:

checkcast java/lang/runtimeexception

now that we’re convinced there’s no casting involved, we can scratch off these two answers:
“compilation fails because we cannot cast sqlexception to runtimeexception”
“throws classcastexception because sqlexception is not instanceof runtimeexception”

so we throw a sqlexception after all, and you’d expect it to get caught by the catch block and get its stack trace. well, not really. this game is rigged. turns out the compiler gets confused just as we do, and the code makes it think that the catch block is unreachable. for the unsuspecting bystander, there is no sqlexception . the correct answer is that compilation fails because the compiler doesn’t expect a sqlexception to be thrown from the try block – when in fact it does get thrown!

thanks again alexandru for sharing this question with us! another cool way to see exactly what’s wrong here and how the sqlexception actually gets thrown is to replace the catch block and make it expect a runtimeexception instead. this way you’ll see the actual stack trace of the sqlexception.

2. tostring(), or not tostring(), that is the question

with only 24% of correct answers, the following question was the runner up on the tough scale.

this one is actually much more simple, just from looking at line 12 we can see that this code prints out m1 and m2, rather than, m1.name and m2.name. the tricky part here was remembering that when printing out a class, java uses its tostring method. the “name” field was artificially added. if you miss that and follow the rest of the code correctly, you might be tricked to choose m1 & new name.

this line sets both names to “m1”:

m1.name = m2.name = "m1";

then callme sets m2’s name to new name, and we’re done.

but this snippet will actually print out something like this, including the class name and hashcode:

myclass@3d0bc85 & myclass@7d08c1b7

and the correct answer would be “none of the above”.

3. google guava sets

this question didn’t really require specific knowledge of guava sets, but left most of the respondents confused. only 25% answered it correctly, the same as choosing an answer at random.

so what are we seeing here? we have a method that returns a set containing a “clique” of a person’s best friends. we see that there’s a loop that checks if a person has a best friend, and adds them to the results set. if a person indeed has a best friend, it repeats the process for them, so we end up having a set of best friends until we reach a person who doesn’t have a best friend or that its best friend is already in the set. that last part might be a bit tricky – we can’t add a person who is already in the set so there’s no potential for an infinite loop.

the problem here is that we’re risking an out of memory exception. there’s no bound on the set so we can keep adding and adding people until we run out of memory.

by the way, if you’re into google guava, check out this post we wrote about some of the lesser known yet useful features about it .

4. double brace initialization, lol wut?!

this one was one of the shortest questions, but it was enough to get most of the developers confused. only 26% got it right.

not many developers are aware of this syntax that comes in handy when you need to initialize a constant collection, although some side-effects are included . actually, this lack of popularity might be a good thing. so when the wat?! effect wears off, you can see that we add an element to the list, and then try to print it out. normally you’d expect it to print out [john] but double brace initialization has other plans in mind. what we see here is an anonymous class that is used to initialize the list. when it tries to print out names, it actually comes out as null. since the initializer wasn’t consumed yet and the list is empty.

you can read more about double brace initialization right here .

5. the curious case of the map at runtime

this one is another community-contributed question coming from barak yaish from israel. only 27% of the participants were able to solve this question.

alright, compute looks up a value in the map. if it’s null, it adds it and returns its value. since the list is empty, “foo” doesn’t exist, v is null, and we map “foo” to a new arraylist<object>() . the arraylist is empty, so it prints out [] .

for the second line, “foo” does exist in the map so we evaluate the expression on the right. the arraylist is cast to a list successfully, and “ber” is added to it. add returns true and that’s what it prints out.

the correct answer is [] true . thanks again barak for sharing this question with us!

bonus: and the easiest question is…

this time we have a question coming from peter lawrey of openhft who also blogs on vanilla java . peter is on the top 50 list of stackoverflow and this time he moved over to the other side and asked a question that 76% of you got right.

answer c is simpler than a, b & d doesn’t compile.

conclusion

from time to time we really like playing this kind of puzzles to sharpen our java knowledge, but if you ever find yourself spending too much time on these puzzlers in your own codebase, it will probably be less than ideal. especially if someone calls in the middle of the night to fix a critical production error. for this kind of situation, we’ve built takipi for java . takipi is a java agent that knows how to track uncaught exceptions, caught exceptions and log errors on servers in production. it lets you see the variable values that cause errors, all across the stack, and overlays them on your code.