Client java version

Would adding a bot written with JDK9 and compiled with robocode would create a problem if there was an error with JDK9?

If there is an error in JDK, than sure it will be a problem.

But there might be a problem with JDK9 compilation, even if jdk9 itself is good, if the rest of us run literumble with java8. You bot might even not start in our clients.

Couple years ago when java transitioned from java 6 to java 7, we had this issue in rumble. People who made their bots with more recent java were in disadvantage and their bots showed a lower score.

I would suggest to cross compile your bot to java8 version, since according to the poll the rest of us run java8. Or go to extremes and make it compatible with java7 via retrolambda, as User:Xor does.

Java 7 compatible is a very good idea, I am on 1.7_051 (but intend to go to JDK 8 in the near future) and can't run battles for a handful of bots. Just look at the missing pairings of GrubbmThree 0.9a. Btw, other clients should do those, why don't they. But it seems that there are also a few bots that can't handle a Java 8 client, like tcf.Drifter and sm.Devil (see comparison between GrubbmThree and MaxRisk)

There is something fishy with literumble. In console, I see a lot of entries like

Ignoring: gh.micro.GrubbmThree 0.9a,cb.nano.Insomnia 1.0,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,dsekercioglu.ColdBreath 1.9,SERVER
Ignoring: dsekercioglu.HammerR 1.1,gh.micro.GrubbmThree 0.9a,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,suzushin7.nano.Galaxy03 1.01,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,nosteel.Welby 0.0.3,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,cs.PumpkinPie 1.0,SERVER
Ignoring: cb.nano.Insomnia 1.0,gh.micro.GrubbmThree 0.9a,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,dsekercioglu.Husky 1.9,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,dsekercioglu.Wyvern 1.0,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,dsekercioglu.Hammer 8.6,SERVER
Ignoring: theo.Hydrogen 2.1r,gh.micro.GrubbmThree 0.9a,SERVER

Nothing to do with MS products, just an indirect download link. Dropbox and Google Drive do this as well.

Direct download link: https://qevpmw.dm2304.livefilestore.com/y4mj6ooicv7LFLWmhTf1-ozrosL2kMwHPfHvkZe77l8RQ6WUHPgBUlU3jh5ty3cqIgmjMjT94WgbXlvk7Kf3Wqhuft-mcv8ZhBZ5t5mL662MRNHJfTuEqA9Kx1NPU3_vM9VA9-m6i_MMlswLF6cJZmpYzx0oqrP-YIXlpNzTVRleyRYH4wAA-rvVXwF53qExNPYeRPUfUcAlz51BGUEQfONaA/gh.micro.GrubbmThree_0.9a.jar?download&psid=1

That link broke too. (Apparently OneDrive direct download links are not permanent.) Luckily, Rednaxela's server picked it up.

I will look into that this evening, I switched provider, so my old webspace is gone. It explains why I provided most (or all) of the battles although I have separate installs for robocode and roborumble.

Put them (version a b c and d) on GoogleDrive now. Still missing 7 pairings, so I wait a bit before switching to 0.9b

According to the code, it shouldn't be harmful. It's just to make sure the client has the JAR, and to prevent duplicates.

// Check that competitors exist
String jar1 = items[0].replace(' ', '_') + ".jar";
boolean exists1 = (new File(botsrepository + jar1)).exists() && namesAll.contains(items[0]);
String jar2 = items[1].replace(' ', '_') + ".jar";
boolean exists2 = (new File(botsrepository + jar2)).exists() && namesAll.contains(items[1]);

// Add battles to priority battles list
if (exists1 && exists2 && !priorityBattles.contains(record)) {
    priorityBattles.add(record);
} else {
    System.out.println("Ignoring: " + record);
}