exact copy of my solution!

That's true. Nice catch!

Obviating the 3 middle numbers seems rather odd to me (and that's not what the example shows), but if it helps, I've added a comment in the example you found not clear.

That is not as explanatory as you think it is, for example, if I would have this string 12341, I can think that obviating the three numbers in the middle, the answer is True, however as you previosly explain is just the number at the very middle. This kind of things most be explicit explain in the problem description.

Pretty self explanatory given the example, if the length is odd, you should ignore the middle number when adding the halves. You should test the string represents a valid number tho (the middle char included.)

I don't understand problem description, how this number is lucky: 17935 # 1 + 7 = 3 + 5, you are not adding 9 anywhere and do not mention nothing about this. Can anybody explain, please.

Test Cases should be hardest, I found wrong solutions that passed the test cases.

OK. More than 500 people have passed the Java kata (1760); after 500+ people have passed it is impossible to change the tests (CW rule).

This is a long number(9223372036854775807) not BigInteger, you didn't understand my question, I didn't ask for change m from long to BigInteger, what I said is that seeing solutions, shouldn't pass if tested with that number, because of the way they are implemented. I just saying that test cases are weak, nothing else.

Fixed, thanks!

Initial solution says: public static long findNb(long m) so BigInteger m was neither planned nor asked for Java... only long!
If you want BigInteger take a translation with them:-)

None solution should pass if tested with this as input parameter 9223372036854775807. Must use BigInteger instead.