I personaly forgot about ".join()". Thanks for reminding me!

I like that the author thought about readability and moved the most complicated part into a separate method. Best practise for me.

I gave it an "clever" vote. It is nice and all - but when I would stumble over this line in production code I would spend more time on this than on a 3 line solution that is more verbose. It gets all the clever points but only half the "readability points". ;-)

Wow... this is tooooo complex for such a simple problem. Also the code is pushing all into one method (does not make use of levels of abstraction) therefore it is very hard to understand/read.
Upfront declaration of all variables is also an bad practise only used in languages where the compiler needs this. Declare the variables where you need them.
And most importantly: Use the language features/ default functions instead of coding everything from ground up yourself.

This loop in one line thing is not readable and should be avoided. It is the most important part of the business logic and thus must be clear as day on whats going on there.
Multiline statements in general are not a good practise. If you come across code like this late in the day, you could overread a statement more easily and thus waste time.

Free yourself from XML addiction!
If you want to go with your approach, choose another symbol for "row end" and "entry end". You don't need to write verbose xml inside your code.
Also why public getCoord? Nobody should use this. Its the guts of your solution. Hide it!

In general, building this string just to convert it into an array is questionable. Why not define the needed array directly as an array in the code. Hardcoding constants(!) is a good thing.

This is for sure not a good solution. The code is basicly manifested duplication. With a little investment in a suitable datastructure for the locations, the whole thing will become smaller and still remains changeable/readable.

My solution is nearly exactly the same. Only difference is that I used i-- instead of --i .
Is there a reason that you used --i or is it just a habbit for you? (I guess i++ was allways the "default mode" for me since university times....)

I know its just a kata, but I would recommend not to get used to this "comments and indentation" segmentation of code.
Extract methods for that. If something is obvious, do not comment it at all. (i.e. the first one)

Another best practise to have in mind is to exit early. Your break only stops the inner most loop. So in fact you will find the last possible "index i solution". In case of huge amounts of numbers this would be not efficient. Better return immediately when you have a result.

I'm puzzled. By sorting you are changing the indices. On the other hand... nobody said you are not allowed to mess with the input.... sneaky

plain old Java

The default test should use assertArrayEquals instead of assertEquals because assertEquals with arrays is deprecated.