Hello jhoffner,
just as a friendly reminder: Can you please review and approve this change? I added the sample tests :)
I also solved the issue in the kotlin translation https://www.codewars.com/kumite/61f3c1737c4cb1000fb8d896?sel=62680f8514c014000fe0e884

I added forks for Java and Kotlin to solve the issue. Would be great if someone can review the changes and solve this issue (:

Tests was missing because the origin kata had non. I added some sample tests :)

I created forks to solve the issue in java and in kotlin translation:
java -> https://www.codewars.com/kumite/62686f319e736f67f1c8413a?sel=62686f319e736f67f1c8413a
kotlin -> https://www.codewars.com/kumite/61f3c1737c4cb1000fb8d896?sel=62680f8514c014000fe0e884

It would be great if someone reviewed and approved it :)

Thank you for the help. I created a new Fork which solves the Issue in kotlin -> https://www.codewars.com/kumite/61f3c1737c4cb1000fb8d896?sel=62680f8514c014000fe0e884

It would be great if someone reviewed and approved it.
Should I also Fork the Java Kata? I solved the issue in the kotlin kata because I published the translation.

I tried to update the kotlin translation created by me but I don't see any effect when I push the 'Re-Publish' button.
Can someone help me?

It's not that difficult. Just train it, it is very useful. I like to use vectors for movement on a (n x m) field. In kotlin I just use a Pair<Int, Int> for a vector and I add a function for moving.

  operator fun Pair<Int, Int>.plus(other: Pair<Int, Int>) = (this.first + other.first) to (this.second + other.second)

or

  fun Pair<Int, Int>.move(v: Pair<Int, Int>) = (this.first + v.first) to (this.second + v.second)

I think it's very comfortable.
I also used vectors in the katas: https://www.codewars.com/kata/5a5db0f580eba84589000979/kotlin, https://www.codewars.com/kata/5b86a6d7a4dcc13cd900000b/kotlin
These are very cool (: Can be recommended ;-)

ok, thank you

If you move the toLowerCase call you can shorten the regex to check just lower cases

Wasn't mean as shout, anyway I cannot edit it to lower case anymore, sorry.

Java Translation

Please review and approve.

KOTLIN TRANSLATION

Please review and approve.

Sorry guys, it feels that you are just against my kata.
I m pretty sure, it is not just a duplicate. This kata teaches you to find the loop in a chain of nodes. It teaches you that it's relevant to to find the exact object instance to solve the problem. This is a relevant fact which is not teached in the other kata.

@Bind4Basics Show me a kata which teaches you to find the same object instances in a chain and this may be an duplicate. But if not I can just disagree.
@FArekkusu and you can use == to compare 2 nodes for identity making the whole "equals and hashCode are overriden" problem go away of course and using == or System.identityHashCode changes everything. It's an complete other result and not irrelevant which one you use.

Furthermore this kata has want the exact loop. From beginnig to the end. Because it wants an array as result.

The other kata's best practice solution is this https://www.codewars.com/kata/reviews/5490bcb1efb59728f60001ce/groups/54ab01f115613cddeb001939, so it obvious just teaches you to find two equal objects in a chain. And not the same object instance.

I think the setup of this kata is not so bad as you guys say. It makes sense that you have a node which wrapps an value. Also the overriden equals and hashCode methods makes sense. It teaches you to find the same object instance in a chain.

Please reconsider your opinion and respect my arguments.

Thank you for your feedback. I want to say the other kata (https://www.codewars.com/kata/52a89c2ea8ddc5547a000863) describes a problem and the solutions may sove the problem. Because the problem is to find the same object reference in the chain and not an equal object in an chain. So I tried to describe a similar problem which has restrictions to just accept corrected solutions.

Also to return an array of numbers means that you also have to find the begin of the loop and not just the count of the loop, which you could also find without finding the first node of the loop.

So my suggestion is to wait for more feedback. If you say it's not different enough I will come back to your idea with the O(1). An idea to detect the performance restrictions could be to add a callCounter to the next node method. What do you think?