JAVA UNUSABLE

[amstan]

I'm sorry, it is pretty difficult for us to update Java.

[kevin_flynn]

Java VM: OpenJDK 64-Bit Server VM (1.6.0_0-b11 mixed mode linux-amd64)/w IceTea

I haven't encountered IcedTea on a production server before - perhaps this is the source of the Java problems, or perhaps not.

Personally, I've been enjoying "playing along at home", in parallel with proper actual challenge; I don't have time to rewrite my entry in another language and don't expect the organisers to address the apparent issues: They won't even acknowledge or deny the problem exists (which is starting to annoy me, sorry).

Looking at the current top 50, there is manifestly a problem with using Java. It's an extremely popular language, yet at the time of writing, its only representative in the top 50 is at position 40. C++, Python, C#, Go and Haskell all have multiple representatives above that and Lisp makes a showing too. All other things taken into consideration, this seems statistically extremely unlikely without the hypothesis that Java is being almost completely disadvantaged in this competition.

I think it's bad form for the organisers not to publicly state one of:

a) there is no problem (and explain the anomaly),
b) there's a problem and we will fix it, or
c) there's a problem but we won't fix it, sorry.

[dutchflyboy]

Well, amstan seems to acknowledge the problem and says that it won't be fixed (for the time being at least):

I'm sorry, it is pretty difficult for us to update Java.

[amstan]

For now all that us, the organizers, know is that 2 submissions time out and they're both using java. This could be the source of anything from java vm crappieness(since we're not changing this it's your responsibility to test it on what we're running) to bad code.
There is an ample amount of languages to pick from, if java does not suit you perhaps you should try something else. We installed the language packs the way it is found on other systems too(from the repository) and this does not mean bleeding edge.

[kevin_flynn]

Thank you for a response.

The requirement that every entrant needs to install Redhat to test their entries seems to have escaped all of your documentation.

[amstan]

The requirement that every entrant needs to install Redhat to test their entries seems to have escaped all of your documentation.

That is not a requirement.

Also, if you need that java please follow a few links from here: http://www.google.com/search?hl=en&q=openjdk+download+1.6.0&aq=f&aqi=&oq=

[kevin_flynn]

Also, if you need that java please follow a few links from here: http://www.google.com/search?hl=en&q=openjdk+download+1.6.0&aq=f&aqi=&oq=

I don't think you understand the situation.

If you read the top search result, you will see that IceTea, the JVM that you are using, is listed only under Fedora 9.

If you read the whole page, you'll see there's no build for Windows or, Mac OSX (the two OSs I have at home).

And if you read the second search result, you'll find: RPMs, build instructions for Redhat, and I quote "Additional instructions are also available for Debian, Fedora, RHEL 5.x and Gentoo. These may be outdated." No thank you, I don't fancy trying to build an entire JDK on Debian (my server OS) which is probably not fully supported.

Iced Tea is a Java runtime explicitly produced by Redhat to address the remaining licencing issues with Java. It's based on OpenSDK, but it's no more OpenSDK than the standard Java published by Sun (as was) which is built from the same base.

By taking the stance of expecting that people test their bots on the Java runtime you have installed, you are de facto requiring them to run Redhat, or at least a close Linux variant onto which they have to install an RPM or build from source. And given that this is an AI challenge and not a competition in building and installing Linux packages, I stand by my statement that you have made Redhat a requirement.

And none of this gets us any closer to finding out why so many people are having problems with Java timeouts; there are more than just two people, I counted 6 on this thread alone.

PS: This is of course, simply my understanding of the situation based on what I've read, and I welcome any corrections.

[thedeadwalrus]

I strongly suspect the problem is with the VM; specifically with the VM and its access to the system timer.

The result is that it is impossible for me to time my bot's moves. When I remove the timer function and just guesstimate how many iterations can be run, my bot will work fine -- as long as I'm properly conservative.

But this is a crappy hack of a solution. It would be lovely to be able to call System.currentTimeMillis() or the like without generating random timeouts.

NOTE: I am not suggesting that it is not my "crappy code" that is causing the timeouts. This is a distinct possibility. But without any debug information when I get a "1s/move" timeout this is really impossible for me to determine.

It would be awesome if I could get a log when this happens. But, barring this, Would it be possible to at least let us look at the game up until the timeout occurred? I.e., a partial game up until the 1s timeout disqualified my bot?

[mspang]

And if you read the second search result, you'll find: RPMs, build instructions for Redhat, and I quote "Additional instructions are also available for Debian, Fedora, RHEL 5.x and Gentoo. These may be outdated." No thank you, I don't fancy trying to build an entire JDK on Debian (my server OS)
which is probably not fully supported.

contest:1015:~% cat /etc/debian_version
5.0.4

contest:1016:~% java -version
java version "1.6.0_0"
OpenJDK Runtime Environment (build 1.6.0_0-b11)
OpenJDK 64-Bit Server VM (build 1.6.0_0-b11, mixed mode

I agree that we shouldn't have starter packages that can't be used. We can prevent further people from running into this by simply removing the starter package. Java is unique among all of the starter package in that its runtime can't seem to handle running in our sandbox without timing out. It's worse even than interpreted languages like Python and JavaScript.

[callinwire]

Well, anyways, a few days ago I converted my entire bot from Java to C++, without making any changes to the algorithm. After doing this (I was even able to copy and paste a lot of the code), I no longer experienced any timeout issues.