My Brazilian ass cannot comprehend tip culture at all.

Tenary operator explanation was the key in this context - thanks.

Assuming you're more familiar with C#:

int in Java is a primitive type, which is akin to what C# calls value types; int alias Int32 is a value type in C#. They cannot be null in either language, they always hold a value.

Integer in Java on the other hand is a boxed integer, which is an object (what C# calls a reference type) that CAN be null. The closest thing C# has is nullable types: int?. Boxed types are usually mixable with primitives because the Java compilers performs auto-unboxing (i.e. converting back to a primitive) as needed.

Now to the particular error you're getting (Cannot invoke "java.lang.Integer.intValue()"): this is a well-known quirk of the ternary operator in Java. Your code boils down to this:

"a".equals("b") ? 0 : ( "a".equals("c") ? 1 : null )

Here the specifications for the ternary operator say that the nested ternary has type Integer, because the first option 1 is an int so the second option null is interpreted as a null reference of type Integer (it's the only way to make those two options compatible). But for the outer ternary, the reverse happens: int as first option, Integer as the second. The compiler does not know that the second option is null, it auto-unboxes it to a primitive int, so you get a NullPointerException.

It's as if you had written:

Integer nullable = null;
Integer retval = false ? 0 : nullable;
// the compiler treats this as:
Integer retval = (Integer) (false ? 0 : /* throws: */ (int)nullable);

You have a detailed explanation of the relevant rules in the stack overflow thread I linked.

null as Integer? => NullPointerException
i do understand the Java is a higher state of mind - but null as Integer?

python round() is screwing the results up

warning cleared

Thanks. It was just a typo. Have a nice day;

Your solution has a bug, it is not a kata issue.

like this one

Enabled in this fork

Duplicate?

Remove those silly arguments checks. If you do keep them in for some reason, change the return type. We now have mixed return types :/

Java fork (author inactive)

• upgrading to JUnit 5
• displaying the input in assertion messages
• removal of Integer constructor, which triggers deprecation warnings (fixing this issue)