Indeed - legions of C++ programmers from the games industry who were desperate for anything, just anything to get them out of the hell of doing recompiles jumped on the first thing that wasn’t utterly utterly abysmal. The poor things don’t know any better. (If they did they’d have been using Java in the first place, hey ho)
Cas 
You could also use clojure as a scripting language. Clojure compiles source code to bytecode on the fly just like janino, but it has lambdas.
I want one where i can do autocomplete one the netbeans framework and setup some ‘special’ global objects filled in from the larger program. Guess Janino would work except for the lack of generics (one of the ‘special’ objects would be a map).
Currently thinking of groovy too. The idea of the program is not some general thing, just some ‘unit of code’ that are executed unconditionally if the selected thing is selected, so having the declare classes and stuff like that would only be harmful.
Clojure is on my radar, but just because it compiles to bytecode doesn’t mean it’s going to offer a comparable speed to Java, or necessarily be fast enough for what I’m thinking of using it for. Interesting to note the differences here for example - http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=java&lang2=clojure
clojure and janino are definitely aimed at two very different use cases. While even idiomatic clojure can be fast, it depends on which idioms you use and which you avoid. Even then there’s a runtime library dependency, difficulties in calling back in to clojure code, and finally there’s the small matter of the source language being completely different …
Janino can run on just a JRE, but if you already have a whole JDK, you can just as easily use javac itself through the tools interface. And I don’t think it all that unreasonable to require anyone using the script development features of your app to have a full blown JDK.
One of the awesome things about Java is not just that you can dynamically load stuff using classloaders and thus partition mods, but that you can just plonk a jar or three in front of the class path and actually override existing behaviour (especially cool if you give away the source in the first place!) Then anyone with a JDK can basically tweak your game to their hearts content without actually having to do a full build.
Cas
Unfortunately, that’s the one thing I’m wary of doing - this wouldn’t just affect people using the script development feature, but then anyone who used the projects with custom scripts, including when they’re distributed as standalone apps. They’re always compiled on the fly.
If you allow people to edit scripts or use custom ones, then yeah, they’re using the script development features. My take is if you’re using Java as a source language, you’re probably dealing with java devs anyway. Otherwise you should really use a DSL that’s more appropriate for the domain.
I’m told Groovy is really quite fast these days, or at least can be made to be if you use static types.
Without wanting to hijack this thread too much more … 
In Praxis LIVE you can create a project with custom scripts. You can then distribute that project as a standalone executable to people who aren’t Java devs - the scripts will still be compiled on the fly, but I think it’s unreasonable to expect all the recipients to have a JDK installed. Of course, I could have projects include the compiled bytecode too, but there are other reasons not to.
It could be the same with game mods - there’s something nice about allowing mods to be distributed but enforcing that’s done in source format.
And while I appreciate your point about DSL’s, the other options do mean you lose speed! Unless you wrote one that compiled to Java source and you then compiled that on the fly, but that’s going around in circles now! ;D
Not necessarily. It would be pretty easy to write a DSL for the JVM that outperforms Java in some areas.
There is a grey area between a declarative DSL and pure data, or between a DSL and a highly structured API.
I don’t know how much space the JVM instruction set leaves to outperform Java, but I imagine it would be pretty hard (even relative to coding your own compiler for the JVM.) Maybe something as fast would be relatively simple. It depends on what the JVM is capable of. Do you have an example scenario where it would execute faster?
float foo(float x) { return x + 0.f; }
Stay away from scripting languages as long as you can.
As soon as it is necessary for someone non-developer (end users, designers, …) to change some behavior in the program WITHOUT having the full development environment (jdk, IDE, etc…) THEN consider using a scripting language.
And before diving into full blown languages, perhaps configuration files parsing could be enough.
Worrying about performance is just masturbation IMO.
Unless you’re trying to code a 3d engine with Groovy.
I’d say do the math: Do you have a reasonable expectation to save over twice the total development time (including risk, maintenance, etc. etc.) over not using a DSL. If the answer’s no, then pass. Attempting to out-perform Java is an unlikely goal for a game DSL.
Worrying about performance in performance critical code is never just masturbation IMO! 
One of Janino’s key uses is as a live function compiler for repeatedly called functions. Personally in my comment above about lamdas I’m particularly thinking of live-coding things like audio DSP. There is a VST plugin somewhere that embeds Janino for this very purpose.
Now, that’s a less likely thing for a game mod, but there are things like pixel ops, procedural textures, physics functions, etc. which could be quite interesting to mod on the fly, but still need high performance. Admittedly, some of those are possibly better done with live-modified GLSL shaders, but that would be a performance choice!
My key thinking is that game code and user modded code should have (the potential for) equal performance.
Er … any useful examples that don’t involve programmer stupidity?! ;D
That’s not programmer stupidity. It’s a useful function: converting negative zeros into positive zeros. Just most people don’t care about that. That’s just the most trivial example of a transform that’s illegal for Java the high level language to perform that popped into my head. Floating point is loaded with these kinds a transforms.
a+1+1 != a+2
(a+b)-a != b
a/10 != a*(1/10)
etc, etc.
The strictness of Java the high level language makes many transforms illegal.
Ah, OK, see what you’re getting at - an explanation would have been good (for me at least! ;D )
You wouldn’t write performance critical code with a scripting language, would you ?
I hope not, for your sake…
No, and I think I see my point flying over your head somewhere!
There are some (not many, admittedly) interesting uses for allowing people to modify performance critical code at runtime (I gave some examples). My point is exactly that I wouldn’t use a scripting language for this purpose, in which case it comes down to live-compiling and inserting Java code at runtime. This is the whole reason why Janino exists at all!