Hi all,
Is there a way to dynamically compile a .java file during run-time?
Thx, DP
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.
This works on Windows, I dunno about other OS’s.
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");
}
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.
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
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
Have you considered beanshell for this purpose?
Kev
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
[quote]Edit: Darn it, janino is under LGPL. That means I can’t create a profitable game with it can I?
[/quote]
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
Uh, whats with this sudden exodus away from LGPL at the moment?
There was that whole discussion about what exactly LGPL means in Java…
Kev
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.
But are you allowed to distribute tools.jar independantly of the SDK?
Kev
[quote]There was that whole discussion about what exactly LGPL means in Java…
[/quote]
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
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.
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
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… 
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
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.