Rednaxela

Posted a possible fix for compatible getName() behaviour while also avoiding risk of bugs akin to in the past: https://github.com/robo-code/robocode/pull/58

Interesting. I'm a little surprised at caching and reflection behavior being related to the JarJarTest failure in OpenJDK 11. When building in OpenJDK 11 I did notice some warnings about reflection stuff that was deprecated and wouldn't work in the future, but the warnings gave the impression that such worked just fine in OpenJDK 11, which is not Java 16+ where the reflection stuff actually stops working, rather than just warning about it.

JarJarTest Fails in OpenJDK 11

Unfortunately, sticking to 1.9.4.1 isn't an option for the rumble either, at least for Teamrumble/Twinduel, because as of 1.9.4.1 getTeammates/isTeammate are very broken, and are relied upon heavily. It could be modified of course but I don't think the current version of literumble supports setting different required versions for the different leagues either, so short-term options are likely either: - stick to 1.9.4.2 for now until there's a fix, temporarily removing bots it's known to affect (which...

Unfortunately, sticking to 1.9.4.1 isn't an option for the rumble either, at least for Teamrumble/Twinduel, because as of 1.9.4.1 getTeammates/isTeammate are very broken, and are relied upon heavily. It's rather unfortunate that some bots relied on getName() in a way that was not meant to be relied upon, but at the same time bot authors had their reasons for wanting to detect some configurations of multiple of their own bot in a battle and that was definitely the path of least resistance to accomplish...

After considering this further, I believe the most likely thing is that ABC was using the result of getName() to detect the special case of multiple instances of Tron versus itself, to behave in a special way for test purposes. I was hearing from Xor on a wiki thread that there are also some teams out there that look for (1) to assign one bot to be leader. Most teams I looked at in the past didn't do this (either no leader or used a different class), but apparently some did. In my opinion, the change...

Tron's change in behaviour seems to be a consequence of the change in what getName() returns. As a test I repackaged Tron with (1) added to it's version field, and it exhibited the same behaviour in 1.9.4.2, when in 1.9.4.1. See the attached abc.tron3.Tron_3.11_T.jar for a repackaged copy of Tron that misbehaves even in 1.9.4.1.

So I made a quick little simple test bot (ags.bugs.ShouldBeGreen 1.0), to see if it reproduced what was going wrong for Tron, by bundling a properties file in the robot data directory, and reading it. If it works right, the test bot is green, but if it fails the bot will be red. Turns out green however even in 1.9.4.2, so whatever is going wrong with Tron is a little bit different somehow. I wonder if maybe Tron was using it's own name in some fashion, but if it was it was already stripping the version...