Talk:Other JVM Languages
"Support for languages which don't have a compiler will require changes to Robocode which nobody has yet volunteered to implement." I don't think this is entirely correct. Pavel has been hard at work adding support for .NET to Robocode, which I believe would add support for some other languages. Someone who knows more about it should add a note about that, though. --Voidious 16:22, 24 January 2010 (UTC)
I haven't been following his work on that front, but if his work is concentrated on loading .NET assemblies, then the comment is still valid. For non-compiled languages, you would still need some custom code for each language to load the interpreter and parse each source file to find classes which extend Robot.--Duyn 02:35, 25 January 2010 (UTC)
- No, basic Scala has already been implemented, as I write below. Sorry =) --Nat Pavasant 10:35, 25 January 2010 (UTC)
Robocode in Other Languages
- .NET Robocode is almost completed. I was just reqested by Pavel to do QA on it. It should be beta release soon. For those who is interested in, Pavel has created jni4net library that connect .NET CLR and JVM through JNI. Earlier he code it just for Robocode, but he and Fnl decided to separated the project for other to use it too.
- I've requested PHP for Robocode too. Take a time search, PHP-Java bridge seems to do well.
- Python and Ruby can be implemented via Jython and JRuby, but nothing has done yet.
Note that people have tried to use Python for Robocode before too, but experience problem. And those robot cannot run in Competition until it make official. --Nat Pavasant 10:35, 25 January 2010 (UTC)
- I think the information is useful even if people can't enter their robots into any official leagues. Robocode gives a nice practical way to learn a new language, and this page can help people get up and running quickly. The alternative would be having people find this stuff out themselves (the clojure stuff was especially unpleasant).
- Scala robots run fine. I have coded a basic guess factor targeting bot (similar to the algorithm used in the GuessFactor Targeting Tutorial) in Scala which is putting my pattern matchers to shame. I have not yet encountered a feature blocked by Robocode, though I don't use structural types because they require reflection and are thus slow.
- I tried out the Scala demo robot today. It runs great in the first battle, but in the next battle it is crippled by a NullPointerException apparently caused by Math.abs(). I read somewhere that Scala doesn't have static/class methods; so the Math functions are implemented as instance methods on a singleton object. Presumably, the singleton Math object is getting destroyed at the end of the first battle and not properly reinitialized for the second. Does anyone else have the same problem, or maybe even know how to fix it? Thanks. I'm running robocode 188.8.131.52 Beta 3.
There was a time when Scala robots required specific changes to Robocode, back in the days when Robocode would only let you load classes from the CLASSPATH if they were in the java.* or robocode.* packages. That is no longer true now that Robocode seems to let you load any class you want from the CLASSPATH. —Duyn 13:53, 25 January 2010 (UTC)
- Well, you could have help us in Scala implementation. Contact me if you interested.
- What I was worry at is when Robocode released plug-in which implement those languages, and if some newbie who are coding in, for example, Scala come across this page too, they might confused. --Nat Pavasant 14:06, 25 January 2010 (UTC)
- For Scala, you don't need any extra effort. The Scala library just has to be on the CLASSPATH that Robocode is run with. Once that is done, everything just works (tested on Robocode 184.108.40.206).
- Clojure requires disabling the security manager because (on Windows) it tries to read the file
\C:\...\clojure.jarwhen the correct path to its runtime is
C:\...\clojure.jar(no initial slash). I'm guessing the problem is with Clojure, since Scala doesn't have the same issue.
- As for any upcoming plugin, we can update the information when that happens. Until then, this page can help them get a start now.—Duyn 01:30, 26 January 2010 (UTC)
- If you change the startup script so it doesn't clobber the system CLASSPATH, i.e. (on Windows):
java -Xmx512M -Dsun.io.useCanonCaches=false -cp libs/robocode.jar;%CLASSPATH% robocode.Robocode %*
- then Robocode will automatically pick up language runtimes on the CLASSPATH and enable robots compiled in those languages. After that, you can just tell users to add their (compiled) language's runtime to their CLASSPATH if they want to use it with Robocode.—duyn 02:10, 27 January 2010 (UTC)
- If the distributed scripts were changed in this way, the user would not have to do anything other than ensure their language's runtime is on their CLASSPATH.—duyn 10:10, 27 January 2010 (UTC)
It would be not secure to distribute Robocode with Scala on CLASSPATH because scala is not secure. We will not do that until the security of scala is solved by scala community. Probably never. Please read this  Pavel 18th Feb 2010
- Hi Pavel, you say in that link in solution #1 that reflection doesn't work in the Robocode sandbox. I've found that this is not true, at least for some of the simpler varieties of reflection. I've successfully tested a robot with simple reflection in both Robocode 1.6.x and 1.7.x with no issues at all. Is it only some aspects of reflection that are disabled? Should I post the reflection code that is working inside a bot? --Rednaxela 22:15, 18 February 2010 (UTC)
- I haven't tested yet but there is a test that does Reflection and blocked by the security manager (or else the surefire test will fail). But I remember sometimes I am able to use Reflection too. --Nat Pavasant 13:47, 19 February 2010 (UTC)
- I've tested that specific one myself and it *only* blocks the reflection in that example if it has the setAccessible(true) calls in there, which are unnecessary in that example, and so far as I know unnecessary in most saner use of reflection. This is safe because it doesn't allow any more access to things via refection than it would have without reflection. It is an issue for some dynamic JVM languages however because apparently some call setAccessible(true) for things that they already have access to, plus some things like PicoContainer have a couple modes of operation that involve writing to private fields (not that I like those modes of operation personally), which are not a security issue if it can be restricted to only allowing access to private methods/fields that are defined within the robot jar itself. I currently have an ongoing email discussion with Pavel about this. Apparently Google's app engine has a java sandbox that manages to allow setAccessible() only on classes within the app itself, apparently with the purpose of improving support for various JVM languages. I currently wonder if a similar approach would be possible with Robocode. --Rednaxela 13:59, 19 February 2010 (UTC)