Thread history
Viewing a history listing
Time | User | Activity | Comment |
---|---|---|---|
20:08, 20 February 2012 | Chase-san (talk | contribs) | New reply created | (Reply to Why init instead of static) |
22:11, 19 February 2012 | MN (talk | contribs) | New reply created | (Reply to Why init instead of static) |
00:40, 19 September 2011 | Chase-san (talk | contribs) | New reply created | (Reply to Why init instead of static) |
00:36, 19 September 2011 | Rednaxela (talk | contribs) | New reply created | (Reply to Why init instead of static) |
00:34, 19 September 2011 | Chase-san (talk | contribs) | New reply created | (Reply to Why init instead of static) |
15:05, 18 September 2011 | Rednaxela (talk | contribs) | New reply created | (Reply to Why init instead of static) |
14:33, 18 September 2011 | Jdev (talk | contribs) | New reply created | (Reply to Why init instead of static) |
14:25, 18 September 2011 | Voidious (talk | contribs) | New thread created |
Chase, I believe the reason to use the init method instead of a static block within this class is that the static block won't be called until this class is loaded by the JVM the first time it's used. By using an init method and calling it from a static block in your bot class, you ensure it's called when your bot is loaded, before the battle starts and not causing any skipped turns. Hopefully somebody can confirm/deny that.
Voidious, you right in common, but there're an issue - robots are loaded in theirs threads, so you can skip turns any way.
IIRC, while there is a limit on the time for a robot's class to load, it is far greater than the time allowed per turn.
If I recall, the static blocks are called when the class is loaded (in order they are in the source code).
I forget if it is loaded at the same time or on first reference. I think in robocode all class files are loaded at load time. Which means it doesn't matter where it is initialized in this case.
It's been a long time, but when first writing FastTrig, I believe I tested this, and found that classes like this were initialized upon first reference.
I debugged initialization order. Looks like everything is initialized before the battle starts thanks to some field cleaning algorithm inside the engine (net.sf.robocode.host.security.RobotClassLoader#cleanStaticReference(java.lang.reflect.Field)).