I failed a Java 11 Certification exam

My Answer: “byte vararg”

My Reasoning: “It is the only method that accepts the primitive ‘byte’. It does put it in a list…

When method overloading, if there are multiple potential matches, Java will check them in the following order:

• Exact Match (dhu!)
• Automatic Type Conversion (ex. widening int -> long)
• Automatic (Un)Boxing (ex. int <-> Integer)
• Matching Interface
• Matching Parent Class
• Matching Varargs

There is no exact match, so that phase returns no result. It is however possible to convert/widen a “byte” into a “long”. This means the method (long a, long b) will get called, resulting in the output “long heaven”.

If that method wouldn’t exist, then Big Bytes would be the answer, using boxing conversion to convert byte into Byte.

The answer I gave was the least correct option. 😅 The output could only be byte vararg if:

• the other two methods didn’t exist;
• 1 or more than 2 bytes would passed to the method, as it is the only overload that can handle those amounts of parameters;

My Answer: “false true true”

My Reasoning: “I remember there is some caching happening when using the .valueOf()…

These reference types relating to primitives (Integer, Long, Byte,…) are still reference types. As “==” compares by reference, it would make sense that none of these should be equal.

There is one of these entries that returns true! Apparently, when using .valueOf(), any numbers between -128 and 127 are cached! You can see this if you look at the implementation of Long.

// From JDK
public static Long valueOf(long l) {
    final int offset = 128;
    if (l >= -128 && l <= 127) { // will cache
        return LongCache.cache[(int)l + offset];
    }
    return new Long(l);
}

Integer.valueOf() also uses a caching mechanism which can even be configured using the -XX:AutoBoxCacheMax= parameter.

My Answer: “Doesn’t compile”

My Reasoning: “I’ve never in my life seen a default in the middle of the “case” statements… so I didn’t know if that even is allowed. Also, it hurts my eyes.

• Switch statements tests expressions based only on a single integer, enumerated value, or String object.
• The switch statement evaluates its expression, then executes all statements that follow the matching case label.
• Multiple “case”-keywords are allowed in succession.

The code compiles perfectly 😱 it shouldn’t pass a code review…but it does compile. Here is what happens with each of the statements:

• print(5): Finds an exact match. Because that code-block ends with the break-keyword, we break out of the switch and no other cases are executed; This prints 5.
• print(6): Finds an exact match. The other case statements are ignored and it just jumps into the case body, printing G. We are not done with this one yet, there is no break-statement. We have to continue executing the following statements, resulting in 2 being printed.
• print(1): Doesn’t find a match, so will enter the default case. Since the remainder of 1 % 2 is 1, we print out O. Once again, since there is no break statement, we have to execute the following cases. This means the code will also print G and 2.

This is one of the questions where I doubt if the code compiles because the code is… well…unacceptable? unreadable? Take your pick. 😅