Dynamic Compiling

[darkprophet]

Hi all,
Is there a way to dynamically compile a .java file during run-time?

Thx, DP

[erikd]

Yes, have a look at this:
http://www.janino.net/

It even has a class loader which loads .java source files instead of .class files.

[Malohkan]

This works on Windows, I dunno about other OS's.

1   2   3   4   5   6   7   8   9   10   11

try {       Process p = Runtime.getRuntime().exec("javac "+fileName+".java");       try {             p.waitFor();       } catch (InterruptedException e) {             System.out.println("waiting for compile failed");       }       System.out.println("compiled"); } catch (IOException e) {       System.out.println("compile failed"); }

Games published by our own members! Check 'em out!

[CaptainJester]

Here is an article from Sun's Tech tips newsletter.

COMPILING SOURCE DIRECTLY FROM A PROGRAM: http://java.sun.com/developer/JDCTechTips/2003/tt0722.html#2

All javac does is wrap a call to the class that is the Java compiler.  You can call the compiler directly as a class from within your program.

[kevglass]

Both of those require the user to have the SDK installed. Most game players would only have the JRE.

http://www.janino.net/  - doesn't need it.

Kev

[darkprophet]

thx ericd and kev.

Im doing this because I would like the user to create normal .java files as "scripting" files and gets loaded automagically without making them compile it using javac which needs the SDK.

Has anyone used it? Is it fast for simple classes?

Edit: Darn it, janino is under LGPL. That means I can't create a profitable game with it can I?

DP

[kevglass]

Have you considered beanshell for this purpose?

Kev

[darkprophet]

lol, speaking of the devil. I actually just went to their website and its also under the LGPL license.

The beanshell's website says to email them about other license agreements. So I have.

DP

[rreyelts]

Edit: Darn it, janino is under LGPL. That means I can't create a profitable game with it can I?

No, LGPL just means that you can't make modifications to the source code of Janino, w/o releasing those source code modifications to the people you release your program to. Unless you think you'll be needing to rewrite Janino source code, that's a pretty liberal license.

God bless,
-Toby Reyelts

[Orangy Tang]

Uh, whats with this sudden exodus away from LGPL at the moment?

Games published by our own members! Check 'em out!

[kevglass]

There was that whole discussion about what exactly LGPL means in Java..

Kev

[Jacko]

AFAIK, using the javac compiler like CaptainJester suggested only needs tools.jar to be available on the classpath. It isnt the most lightweight solution as its about 5Mb, but it zips down to just over 1Mb, and its as standard as you can get.

I hadnt heard of Janino before now though, looks like it could be worth a look.

[kevglass]

But are you allowed to distribute tools.jar independantly of the SDK?

Kev

[Orangy Tang]

There was that whole discussion about what exactly LGPL means in Java..

I thought that ended up being a non-event? Or has the uncertainty making people paranoid?

[rreyelts]

I thought that ended up being a non-event? Or has the uncertainty making people paranoid?

It was a non-event to me. I don't know of anybody who is concerned about the LGPL with respect to Java.

God bless,
-Toby Reyelts

[Jacko]

IANAL, but I think tools.jar is covered under the same terms as a jvm, in that you have to distribute it unchanged and complete.

The alternative would be to use Jikes, which I think is quicker and a smaller download. Its C++ code though so you would need a different binary for each platform.

[darkprophet]

Platform compatibility is a must, so differnet binaries for me just complicates things unnessarily.

But is the tool.jar considered a different piece of software than the JVM? If it is, then great, it it isn't, then darn it again!

DP

[oNyx]

janino looks really neat.

I'm wondering how (exactly) it could be used for speeding up the development process...

Let's say you have a neat small engine, which cares about loading media and the like and you could test some classes without having to restart the application again and again (and thus no need for reloading all the media each time). Hm...

[darkprophet]

thats providing Janino is faster than just doing a compile using tools.jar and loading via Class.forname

Actually, that gives me an idea or two...

DP

[swpalmer]

FYI... there is no such thing as Tools.jar on a Mac.  And there is no such distinction between the JRE and JDK on a Mac either - if you have Java, you have the compiler too.  Just the Javadocs and possibly the src.jar are a separate download.

[oNyx]

[... several weeks later... ]

I really love Janino!

Toying around is really really fast now. It compiles in an instant and well... I don't have to restart the vm at all. Doing some changes... save... switch to my brainless shell... press a button... and one second later the new version is up and running (and that with a 500mhz machine with only 128mb ram).

It's really amazing.

On the downside... new 1.5 syntax isn't supported yet, the error messages are somewhat odd (just look at the line number and check it for yourself) and you need to adjust your framework a bit, but in return you avoid reloading media [At the end you can of course compile the usual way... so there is no need to distribute the lib if you just (ab)use it as dev tool]

Oh and if you find a bug and report it it gets usually fixed within 1-2 weeks. That's a big plus imo

Btw the easiest way for preventing getting a cached copy of a class (=not the newest) is using a freshly created JavaSourceClassLoader for loading the class. There is a cleaner way, but it's not worth the trouble (given the rather frequent update rate of janino).

Well, you can't use that approach for everything, but it's great for prototyping or things like getting the collision detection/response just right.

[darkprophet]

thx onyx for this review. I have been a bit hasty in doing this in my game, but ive been given some confidence.

One final question. And probably only you can answer this oNyx. Is using Janino to dynamically compile a "script" and running it as a normal class a better option than using say....Groovy or BeanShell?

DP

[oNyx]

I'm afraid I can't answer that question in general, because it depends on the project if it's "better" or not.

BeanShell is like usual java but slower (interpreted), but there is no compile time. Groovy is also interpreted, no compile time too, but you won't be able to "convert" it to a class at the end.

With Janino it's a bit different. You have compile time there, but it's damn fast (the vm is still running therefore there is no need to start the vm [like javac does]). For example something like hello world compiles in 10msec (whereas javac takes several seconds[slow 500mhz mind you]). You can also customize the class loading a bit... eg if there is a class you load it if not you compile it on-the-fly with janino or you could use a properties file containing those classes which should be dynamically recompiled.

So basically you can keep the compile times of janino pretty low (<1sec), you get the full java-speed and you won't need to ship the lib (and your source) at the end. Those are the reasons why I like it and those are also the reasons why I didn't tried the other options. I want full/actual speed. I want to see/know if I do something horrible wrong (=slow).

Well, having said all that... janino has still several problems. It's for example unable to compile TinyRivers (bombs out with: Operand stack underrun at offset 312...net.janino.CodeContext.flowAnalysis... yadda yadda). However, it seems to be good enough for smaller things (or a bunch of smaller things). It's also good that you can replace it with "com.sun.tools.javac.Main.compile" if you want to (if you've only used the source class loader).

Janino can be also used for smaller things like expression evulator or as a script evulator (but the you'll have to ship the lib).

I suggest giving it a try. It's a pretty interesting piece of tech, which can speed up development (under specific circumstances) a lot.