Slashdot Mirror
Java Native Compilation Examined
An Anonymous Coward writes: "DeveloperWorks has an interesting article about compiling Java apps to run as native appplications on the target machine without the need for a JVM."
← Back to Stories (view on slashdot.org)
Good progress is being made in native compiler for Palm OS. See http://sourceforge.net/projects/jump/
and also http://www.superwaba.org for info on the related JVM for PDAs that it replaces.
Good stuff.
Beta only seems to work for Google. Such a shame.
People think of the VM as an interpreter that executes the bytecodes. That's a particular implementation of a VM. And not a very good one -- which is why no production VM works that way.
The simplest optimization is to use a JIT. This gives you native execution speed once the class files are loaded -- but loading is slower, because it includes compiling the byte codes. You can end up wasting a lot of time compiling code you'll only execute once -- most programs spend 90% of their time in 10% of their code. Depending on the application, you can end up wasting more time on unnecessary compilation than you save by running native code.
Intuition suggests that the most efficient thing to do is to "get rid" of the VM by compiling everything to native code before you distribute your app. But that doesn't get rid of the VM -- it just converts it to a different form. There are some VM features you can't compile away, such as garbage collection. Some experts claim (not me, I get dizzy when I even read benchmarks) that "pure" nativeness is illusory and not that efficient. Plus you lose a lot of the features of the Java platform when you run the program that way. Might as well stick with C++.
Some VM implementations use a sophisticated comprimize between interpreters and JIT compilers. If you can identify the small part of the program that does most of the actual work, you know what parts of the program really need to be compiled. How do you do this? You wait until the program actually starts running!
Advocates of this approach claim that it has the potential to be faster than C++ and other native-code languages. A traditional optimizing compiler can only make decisions based on general predictions as to how the program will behave at run time. But if you watch the program's behavior, you have specific knowledge of what needs to be optimized.
Computer science breakthrough, or illogical fantasy? Don't ask me, I'm just a spectator.
The engineers I picked this stuff up were very contemptuous of "microbenchmarks" like those described in the developerWorks article. Nothing to do with the real world.
First, I have to identify that we (my company) do use the JET byte->native compiler by Excelsior. Good product, I've recommended it to others and they've had success with it too. In our case, it produced a 10-15% speed increase, some in-memory size savings, and it had one huge advantage missing from the byte code: SECURITY!
After experimentation, I'm pretty convinced that the decompilers on the market that work on obfuscated byte code KICK THE CRAP OUT OF THE OBFUSCATORS. The long and the short of it is the decompiled code is pretty decipherable.
If you want to protect your IP (Intellectual Property), that's not a good thing. In fact, that might be (if you are in a competitive arena) a VeryBadThing(TM). The native code (especially optimized native code) is far harder to effectively decompile into something usefully readable which crackers and script kiddies can abuse or which competitors can peruse. This benefit alone makes it worth going this route if you can.
One of the other things the article missed:
It didn't devote much thought to the settings and optimizations these compilers provide. The Excelsior compiler (by example, I looked at Bullet Train and some others before we picked Excelsior) provides ways to disable certain safety checks (like array bounds checks) for extra speed. If you're in a fairly aggressive environment with some pretty significant timing issues (I won't say hard realtime, because anyone doing hard realtime should be using something like QNX), you will find that even these small gains may be useful (and the risks they introduce acceptible). But the article didn't even hint at these possibilities.
So, if you want to build something that is less likely to be cracked or examined, this type of tool is the way to go. Excelsior, for example, is fairly easy to setup. I did get some help from their guys, but only because our product includes OpenGL, QuickTime, a bunch of XML parser stuff, DirectX, sound support, UI, etc. - a whole pile of external dependencies. The buddy I recommended it to had his project up in going in half an hour or so, with a more modest project (but still a useful, full fledged app with GUI).
Undoubtedly, these won't solve all your ills and they may introduce some new difficulties in bug hunting (though some of the new debuggers coming out with these products are very neat also). So you will want to look at what you need, what your concerns are (security, speed, cross platform deployment, etc) and decide accordingly.
-- Mal: "Well they tell you: never hit a man with a closed fist. But it is, on occasion, hilarious."
Further, not everyone even cares about the cross-platform nature of Java to begin with. I've worked on a few projects where the OS requirements were completely fixed but Java was chosen anyway -- for its rapid-design features (built-in garbage collector, nice network access classes, etc) rather than its cross-platform nature.
All in all, its good to have a choice..Just because you can native-compile Java doesn't mean you have to do it.. And in situations where cross-platform is not needed, why not compile to native and get the extra efficiency? Choice is good.
Its a shame Sun spreads so much FUD about native-compiled Java.
Having used JET somewhat extensively, I can say that Swing works beautifully in it... exactly as you'd expect, and at a reasonable speed, to boot. It doesn't make small applications, but it optimizes relatively heavily. There's more than hope: it's already there!
I've had this sig for three days.
While GCJ accepts either Java source or bytecode, it's not clear from the documentation I've read whether or not it first translates source to bytecode or goes straight from source to native.
It goes straight from source to native; for one thing, the source format exposes stuff that allows it to be more heavily optimized by GCC's optimizer than the bytecode format does.
The point is, I can come in and maintain someone else's code with far less trouble if it's written in Java than I can if it's written in C++. Same goes for the support engineers. Same goes for customers. If it's written in C++, the application can essentially be a language unto itself. You have different mechanisms for just about any major feature between development teams; none of them are standard, and none of them are even remotely as easy to learn and use as the equivalent Java API. Maintaining these applications costs a huge amount, and is fraught with support issues exactly because there are so many incompatible ways of doing the same thing.
Your argument is so tired because it doesn't take into account the actual cost of developing real applications--maintenance and support.
Wrong: Those who say that Java is easier to program in (and who don't know C++) really don't want to learn the disadvantages of programming in C++.The only certainty is entropy.
What VM are you using? I haven't seen a significant problem with moving apps between machine architectures since Java 1.3 came out.
I do most of my development on a Windows box, and deploy to Solaris and Linux. It's been years since I've seen a bug only manifest on one of the three systems.
ZFS: because love is never having to say fsck