Client java version

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

I see the problem. Your bot is entered as

gh.micro.GrubbmThree 0.9a,https://1drv.ms/u/s!Aj169YS0AhgMoQVZe6rd5zXnabUE

If I point a console downloader like 'wget' to this link, it downloads some web page and not the bot. You should no better but to trust your files to MS products which break all possible web standards and serve different content depending on the web accessing clients.

Bottom line, we cannot run your bot because literumble clients cannot download it.

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);
}