Yeah, that requires the JDK. Which is a no-go for me because of the license - you can’t redistribute it.
Ahhh. Very frustrating. Still, can be coded around by just not using break/continue… some people say that’s good coding style, anyway, though I’m not one of them 
I got the JavaCompiler version working… Commented out lines are the equivalent Janino compiler code. rcl is my restricted class loader.
//import org.codehaus.janino.JavaSourceClassLoader;
import org.codehaus.commons.compiler.jdk.JavaSourceClassLoader;
...
//JavaSourceClassLoader loader = new JavaSourceClassLoader(rcl, new File[]{new File("").getAbsoluteFile()}, null);
JavaSourceClassLoader loader = new JavaSourceClassLoader(rcl);
loader.setSourcePath(new File[]{new File("").getAbsoluteFile()});
What’s wrong with “Please download the Official Java JDK from Java.com to be able to run this game.”? You could even have the game download it for you from Java.com?
You may not need the whole JDK. If JSR199 is available as a redistributable download, the eclipse compiler implements the javax.tools.Compiler interface too, and that’s bound to have less bugs than Janino.
Call me crazy, but I prefer to have the players run the game using the same JRE that it’s been tested against. Besides, stuff should “just work” as much as possible - a manual step like that means someone will inevitably screw it up and need help, or get mad because the JDK installer installed crapware on their computer (which it does). Everyone is happier when the player doesn’t need to do anything special to get the game running
Hmm, that may be worth looking into. Thanks for the suggestion!
Here’s a crazy thought; What about just using java, as with your original intent? :
You’ll get plenty of speed, and features won’t be hard. You’ll get to call all of your objects directly, and it supports all kinds of fun things.
Does it need to be accessible by players? Read/write, kind of?
The scripts are to be part of game maps (it’s a strategy game) like unit stat calculation, on-hit scripts, campaign triggers, e.t.c, so in theory I could just force people to download JDK for the map editor and keep the compiled Java scripts in the map file, avoiding any compilation during map loading.
I don’t think making modders download a full JDK is all that much of a stretch. Players certainly shouldn’t have to.
Why are they scripts? Do you want the player to change them? Do you have people writing these, that can’t program java?
If no, I see no point in making them scripts.
I would just use the js-script-manager, and do this:
ScriptManager.getScriptManager().invokeWithFailTest(o.getScriptString(), player)
…and you could script it like
function doShizzle(player) {
player.getBackpack().addItem(Items.HEAVY_ASS_SWORD);
}
I mean… just make it easy for yourself 
I don’t think performance is going to be a problem this way.
Just my thought. I realized that I don’t really need the ability to compile scripts in the actual game… >_> Stupid stupid stupid!!!
Oh, I will have lots of scripts. I’ll be having lots of script hooks/functions that can be implemented by scripts and they are then called when the specified event happens. For example, to implement a life stealing attack, you would have a positive buff that gives a unit a script that has a onAttack() function implemented that checks how much damage is done and gives the unit life depending on how much damage you do.
All in all, I will probably have several hundred script functions called each game update.
I don’t know. Let me be an idiot here, for a minute.
Don’t make a game in java, where all the logic is in scripts, and then expect better performance than in java. Either, you keep it java and provide a compiler or you take jython, or jruby and deal with what performance you will get. It’s the price of wanting everything scripted.
/endjerk.
I’m curious; why might you possibly need this? Players who want to mess with scripting, should not have a problem compiling.
I know that wasn’t directed at me but… compiling is a huge pain for a lay modder. If you don’t have to compile, the barrier of entry is really low - a text editor and the willingness to experiment. Once you make them run javac with a classpath set properly and all that, I’d think you’re weeding out the vast majority of people who might otherwise be interested.
Uhmm, my “scripts” are obviously in Java if I use Janino/JavaCompiler. I don’t expect better or even equal performance to Java, just acceptable performance for a game with lots of scripts. I’ve heard that one of the biggest overheads with script interpreters is calling a script / script method. My case of calling many hundreds 1-5 line script methods would therefore be a worst case scenario for interpreted script languages. I’m just trying to do this “right” the first time so I hopefully don’t have to redo it.
Both Mads and Sproingie do have a point that people who want to mess with scripting and such stuff shouldn’t have a problem with installing the JDK, so believe I have “solved” my actual problem here. I’ll compile scripts in the map editor and save them in the files, so only the map editor will need a JDK to compile scripts. The actual game will only load the compiled scripts’ class files. I will continue to keep an eye on Janino though, as implementing it in the map editor would be very nice. I’d also like to implement my stat expressions (like Damage = Strength * 3) using compiled code instead of the external expression lib I’m using right now. This would obviously not be affected by the bug(s) mentioned earlier in the Janino compiler, so I’ll probably implement it when I have the time.
??? I’d obviously do all the compiling in the map editor using JavaCompiler. No need to manually compile scripts. I’ll then have a play button that compiles all the scripts and fires up the game with the map, and also an export function that saves a playable map from a map project with all the scripts compiled so that it can be opened by the game without the need for a JDK. The only thing that the actual modder/maker is exposed to when it comes to compiling is having to download the JDK.
If you want a JDKless alternative for Janino you might want to look at the Eclipse JDT Compiler. It is used in the popular Reporting Engine JasperReports for “scripting” purposes. Maybe you can try Groovy and similar languages that don’t need the jdk for compiling to javavm bytecode as well. In a first prototype it should be easy to implement Groovy, Clojure, JDT Compiler, JavaCompiler… Then you can check performance and ease of use.
Ah, my apologies, that wasn’t obvious to me From what Mads said, it seemed like modders would have to know about “compiling”, which in this case they don’t. They just have to install the JDK, as you said, and the rest just magically works. My mind just didn’t conflate “modding” with “map editor”.
Only just had a chance to follow up. This is exactly what I’d tried out in Praxis without problem - just checking there wasn’t anything more complicated involved. As mentioned, I’m using 2.5.16 and the ClassBodyEvaluator. Which of those helps I don’t know.
I think the SimpleCompiler superclass of ClassBodyEvaluator can compile full Java classes too (personally I prefer using class bodies for user scripts) which might also work OK.
I realise from subsequent replies you may have talked yourself out of Janino by now, though …
Best wishes, Neil
A bit late, but what about Beanshell?
It uses Java syntax too which makes it even easier.
Just to make sure - are you using the same instance of ClassBodyEvaluator to compile both snippets? You have to be using the same instance of JavaSourceClassLoader for the problem to show up.