Hi @jcsahnwaldt, Thanks a lot! I fixed it! Please check again!

Or maybe we should simplify the tests and only use Integer, String and Boolean objects in the random arrays? I'm not sure.

Some language versions of this kata actually only use integers. (Some languages, e.g. C, C++, and Haskell, don't have a type like Java's Object[], and it's much easier to use something like int[] instead.)

Other translations use the three types I mentioned above. I haven't seen a translation that uses as many types as this one. But I haven't checked them all, maybe I missed something...

P.S.: The equals methods of Number subclasses are so strict because equals() must be symmetric: "for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true".

Implementing the equals() methods for all Number subclasses such that they

1. are symmetric and
2. can handle arguments of all other Number subclasses

is impossible, because anyone can add a new subclass of Number, and then the equals() methods of all other Number subclasses would have to be updated. (And even trying to implement this idea only for the Number subclasses in the JDK would be tedious and error-prone, because there are so many of them.)

P.P.S.: I learned about these subtleties from Josh Bloch's Effective Java. Every Java programmer must read this book. Seriously.

Thanks a lot!

Unfortunately, I now realized there's another issue... or actually two issues...

Your solution defines a comparator and sorts the array:

Arrays.sort(retVal, (a, b) -> b instanceof Number && ((Number) b).equals(0) ? -1 : 0);

That's a good idea, but the implementation has two problems:

1. The comparator only looks at the second argument and ignores the first. But Arrays.sort() may call the comparator with a zero as the first argument. In that case, the comparator should return 1, because a zero is considered 'greater than' any other value (i.e. it should be sorted towards the end of the array).
2. In the call ((Number) b).equals(0), I think you wanted to test whether a Short, Long or other Number object has the value zero. But that doesn't work with equals(). The reasons are a bit subtle:

• The equals methods of Number subclasses are rather strict: they only accept their own type. For example, Short.equals() returns false if its argument isn't a Short object (even if it is an Integer object with an equivalent value).
• In Java, 0 is an int literal, and it's boxed into an Integer object in the equals(0) call, i.e. equals(0) is compiled to equals(Integer.valueOf(0)).
• This means that the ((Number) b).equals(0) call only works as expected if b is itself an Integer. For other types, ((Number) b).equals(0) always returns false.
• This in turn means that zero values of non-Integer types are not moved to the end of the array. :-(

The fix for the first issue is rather straight-forward: Just add a few more conditions, check both arguments.

The fix for the second issue is a bit more involved. The random arrays can contain Integer, Long, Byte and Short values. Long has the largest range. Instead of equals(0), you could call longValue() on the Number object and compare it to 0L. Because the ranges of all four types are contained in the range of long, this can never lead to overflow.

Hi @jcsahnwaldt!
I fixed it.
Please check.

Hi @vargajb! Thanks for the translation! Looks good. Unfortunately, the description has changed in the meantime. :-( Could you update it? I'll then approve the translation.

While you're at it, you might also copy the non-random test method from the sample tests to the main tests. It's quite common for main kata tests to repeat the sample tests. Feels like the right thing to do. :-) (Since the main tests then also contain non-random tests, you'll probably want to rename the class from RandomTest to something else. I think it could even be SolutionTest like the sample tests – the two classes are never compiled together.)

The change in the description is probably a small thing and I'd like to fix it myself, but because Codewars' processes are rather frustrating, I'd have to create a new fork, which would start the whole process again... :-(

(I think I'll get a notification when you respond to this message, but I'm not sure. If I don't react for a while, feel free to send me a message at jcsahnwaldt+codewars@gmail.com.)

I fixed it, please check.

Random tests and test cases are swapped.

While I have no idea what a "Best Practice" looks like in COBOL, this is the solution I was going for. I think it is the most readable.

Your solution throws StringIndexOutOfBoundsException wenn the test case begins with whitespece.
All the solutions should give exactly the same result for each input as your asciiConvertToJ function. Your test cases should be improved accordingly.
You should clarify the handling of whitespace characters.
What is whitespace? (space + tab + newline, etc.) --> Please add some new basic test cases. Improve the Kata Description.
Your solution merges multiple whitespaces to a single blank. --> new test cases, improve the Kata Description
It is not clear from the description that the first character of the words must be converted to uppercase and the additional character of the words to lowercase. --> improve the Kata Description
In your solution, you don't take exactly the same characters as whitespace when converting characters (blank, '\t', '\n') and wenn splitting at the end of a function ("\s+").