Good solution! Mine is similar to this one, except I use find instead of filter.

Thats a very good solution. You can instantly see that it has linear complexity.

it looks like the random tests in C# now include large numbers that dont fit in 64-bit integers

Python fork.

It's a bit jank and it uses some hardcoding on my part. It's still possible for the user to hardcode it, but it would be considerably harder.

If you implement a code length check, then it should be very safe, but you'd have to mess with the description. To be honest, that would probably be a good idea.

"The others are just as bad" isn't an excuse. The kata as a whole has issues, it would be good to fix those before approving more translations.

Also, exploiting bad specs isn't cheating, if you don't want people to exploit the tests, then write better tests.

@KayleighWasTaken: Yes, I approved the Python translation, and I think it's OK. Its tests aren't any worse than those for Java and JavaScript. I wasn't complaining about the Python translation. I just was a bit disappointed that literally minutes after I approved it, someone posted a cheating "solution" that took advantage of the lack of randomness in the tests.

I'm working on tests that will be much more random than the current tests. I think I'll need a day or two.

Aren't you the one who approved the Python translation?

...and now Python as well. :-(

Question has been answered.

The problem here isn't that it's a CVE; the problem is that it doesn't work with Java 17. If you choose Java 17 as language version running your solution, it doesn't work. It only works in Java 11. (And the reason was already quoted above.) When Java 11 is eventually deprecated, the kata will be broken.

If you can get it work with Java 17, then it's probably fine, but you'll have to make it work with Java 17 first.

Thanks DasBrain, it does look challenging. Perhaps after gaining an understanding of what's going on here I'll be able to develop an alternate solution to either this challenge or others like it.

Do you have more information about CVE-2012-3174?

While the CVE may use similar things as my solution, it is quite rare to grant untrusted code the ReflectPermission("suppressAccessChecks"), as I do in this kata.

https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/ReflectPermission.html states:

suppressAccessChecks ability to suppress the standard Java language access checks on fields and methods in a class; allow access not only public members but also allow access to default (package) access, protected, and private members. This is dangerous in that information (possibly confidential) and methods normally unavailable would be accessible to malicious code.

This permission was always known as one of those that allow a fully SecurityManager bypass, if abused.

Well, I wrote this - but others did cheat and copy my solution, without understanding what is going on.
Or even changing something.

What can I say?
This kata is not easy - it requires deep knowledge on how the Java SecurityManager works - and the SecurityManager has been deprecated now for a while, so finding people with the right skillset to solve this Kata is hard.

Why is there only one solution to this problem?