Java Native Compilation Examined 486
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."
With your bare hands?!?
What about Java's safety advantages? (Score:3, Interesting)
Benchmarks (Score:3, Interesting)
Re:Finally! (Score:1, Interesting)
The two things that throttle Java's performance are Swing and the garbage collector. Swing isn't *that* big a deal -- like Mozilla's XUL it's been sped up over time -- but doing garbage collecting is a very complex task and will probably eat up CPU cycles like mad for at least the near future.
That isn't to say garbage collection is necessarily a bad thing -- it's good for security and portability (the two things Java really aims for) since it eliminates the need for all those nasty pointers. But it's the main reason C++ code can runs circles around similar Java code. And doing native compilation won't help the situation any.
Microsoft .NET already does it! (Score:1, Interesting)
Garbage Collection Question (Score:3, Interesting)
AmigaDE, Savaje, Symbian and Jeode (Score:3, Interesting)
Re:What happened to Sun's Java chips? (Score:3, Interesting)
Go here [ibutton.com] for more info.
Re:Well gee *that* makes sense.... (Score:3, Interesting)
It seems like you might not have read the article all the way through. It doesn't recommend only native compilation, but it does make a nice comparison between the two solutions. It points out when you might want to take advantage of native compilation, and when it doesn't help. You are always free to generate byte code in addition.
Much of the work I do would be nicer and easier in Java than in other languages, but Java is just too slow and large for my purposes. This gives me the chance to use a language that has a little elegance, without giving up the speed of execution that I require. C++ just doesn't cut it, and it's tough trying to write this kind of code in C (but not impossible, it just takes a little discipline).
Java isn't really cross platform anyway. Where's the JVM for MVS?
Re:Finally! (Score:1, Interesting)
Its a reasonably fast GC, especially if you turn off incremental collection.
Its still a 50% slower than manual memory management on a good day. And you can get a lot faster than either manual or mark/sweep GC with an intelligent hybrid of manual management, pools, and custom allocators. Of course, you pay for that speedup in terms of requiring more sophisticated (read expensive) developers.
Which brings us to the real reason people use Java. Java programmers are cheaper, since you can hire less skilled programmers and not worry about then leaking memory all over the place or blowing away unrelated parts of memory. This effect, along with rampant VM bugs, explains why use of Java doesn't increase software quality.
Re:The article misses some key points (Score:3, Interesting)
That's probably because there's really no way to obfuscate Java byte code, since it's all java.lang.reflectable anyway - you can use Java code to dynamically load a class name at run time and then discover methods it contains and public variables it has.
As far as I know the .class format in essense requires methods and class variables to be determinable makes it fairly hard for Java to be "secure" when it comes to making code hard to disassemble. Especially because all your classes wind up being one-class-to-file and by default end up with the names of the classes and the package structure laid out in the directories created...
Sun may want to consider creating a secure JAR file which is loaded by a "secure" class loader that prevents reflecting, but a lot of cool stuff can be done with the reflect interface (like loading plugin classes at runtime).
Bottom line is that every .class file contains a list of all methods and public variables as well as being one instance of an original class definition - not useful for making your program structure hard to dissassemble. However, the ability to determine methods and load classes at runtime can be useful to. (As well as required for Java's RMI, I think - I might be wrong, though.)
What does native compilation gain me... (Score:4, Interesting)
These kinds of articles raise more questions than they answer. I have to ask what does Java native compilation gain me? Martyn writes in the article that performance and memory consumption were basically a wash on the more complex app, so what are the other considerations that might drive me to use a native compiler?
Native compilers have been here for a long time and they haven't really taken off. They either need to offer something absolutely necessary that I can't get via regular Java compilation and runtime, or they need to offer performance improvements that are orders of magnitude better than what we already have. If the vendors can do that, then I want to talk to them. Otherwise it's just another experiment in an already too busy world. Stph
IBM JRE is surely the winner....but wait.. (Score:3, Interesting)
Don't get me wrong, I'm a big fan of IBM, and IBM has really, really made a JDK multi-times out-performing SUN's JDK.
However, I'd believe the selection of 'opponents' are simily..unfair.
Kaffe is surely an easy-pick. Yes it's the only GPL JDK out there but many people(at least Java developers here) would avoid kaffe as it has a fatal security flaws [kaffe.org] that kaffe team doesn't seem to want to solve it.
Even the GNU people know gcj is slow, even GNU guys know it; but speed is not a real issue for gcj, it's basically a starting point for all implementation - or reference implementation as we like to call it. We would pick a commercial java compiler if we need it.
SUN's JDK, well...you know what I think it just what you think - IT'S SLOW! Yes, we all know that.
Nevertheless I think developer's work is doing a great job here, it confirms something everybody know - that IBM's JDK is fast, and that's it. I don't see it could conclude the performance of native compiled java programs. Unless they include all other commercial java compilers into testing, I wouldn't think we have reached a conclusion yet.
Re:Well gee *that* makes sense.... (Score:1, Interesting)
Binary cross compatibility doesn't exist with java in it's current state. Try byte-compiling on linux and then running it on windows.
Until binary compatibility there is, running with java you will not.
Java Native Compilation (Score:4, Interesting)
Also see on Javalobby the The "native compilation" myth [javalobby.org] and RFEs for JDK1.5 [javalobby.org] threads which discuss native compilation.
Yes, there are some companies like Jet and Jove (and GCJ) making native compilers, but I'd like to see a company of the clout of Sun (or IBM) make native Java compiling more accessable by having a "javac -native" option with their JDK and a smaller standardized runtime (instead of the full JRE) specifically for native compiled apps. The most likely target for native compiled apps running w/o a JVM would probably for the client/desktop side which don't have the resources of server boxes. Remember... it would be an OPTION in the JDK... the old bytecode compiling for VM/JIT would still be there.
It's arguable whether the runtime performance of a native compiled app would be substantially better than JIT compiled (if some of the Hotspot tricks were moved upstream into the JDK compiler?), but there are also other advantages, such as a faster startup time (no need to startup a VM processes and JIT compile) better memory usage (no need for VM process as well as the meta data and bytecode which must be held in memeory). There would also be some drivespace savings as the full JRE wouldn't be needed (though at this time, a developer can't include a partial runtime, Sun wants the full thing if they include one... Sun needs a change of heart and make a standardized smaller runtime for native apps). Also, with native binaries an obfuscator (used for btyecode classes) isn't needed for commercial apps for those who want to keep their code proprietary.
There are lots of suggestions going around for the VM/JIT issues such as loading the VM at bootime, a singular shared VM, and JIT caching. These workarounds aren't neccesary with JVM-less native compiled apps.
Of course, there are WORA extremists who don't like this idea of native compilation because it goes against the dogma of only needing to compile ONCE and run on any OS with a JVM. IMO, as long as the source stays the same, compiling natively for different OS's is still pretty near to the WORA ideals. The Java language is VERY tweaked for portability as-is. It's the OPTION of native compiling that should be available in the Sun or IBM JDK.
Re:The article misses some key points (Score:2, Interesting)
This is not the case anymore. An example is Zelix Klassmaster. We use it for our java web application. No decompiler can cope with it. The decompiled code is littered with byte code that it couldnt work out what to do with. I wrote the code, and I cannot for the life of me work out which methods are which in the decompiled after obfuscated classes. They also do things like String encryption so even string constants are unrecognisable.
Java is certainly not perfect in this respect, but my experience with obfuscation (this is very recent) has been very good.
Re:My Cynical Take on This: (Score:2, Interesting)
I have yet to be proven wrong that developing using C++ is any harder or time consuming than writing in Java. Arguments for usually revolve around Java's libraries and its garbage collection.
To that i say Java's libraries are outclassed and outnumbered by the amount of source for C++ and the number of libraries like Boost
I can even make the case that developing for C++ is easier given the use of templates. Those who say that Java is easier to program in really don't want to learn the advantages of programming in C++.
Not necessarily the VM... (Score:2, Interesting)
The bigger problem is the the programmers lack in understanding the how "Java as a whole" works. Top questions I ask when interviewing a potentional java programmer. Generic questions spawn thoughtful generic answers.
) What's the JVM?
) What's a pointer and how do they work in java. (This one gives you looks.)
) How and when does GC work.
) What happens in the VM when I write "new Object()"
) What does your typical compiler break the follwing line into?
String s = "A"+"2"+new Integer(5)+new String(new byte[] { 66,65,68});
) *Insert ob thread question*
) vi or emacs?
It's not that java is god awful slow, it's b/c it has been hyped so much that non-programmers are getting into the game (not to the scale of VB) and bad code is being written and distributed. I'm not here to harp on non-progrmmers, but I wouldn't hire one for the work I do.
Too many people depend and rely on Java's special features such as GC. The programmer who understands "java as whole" can program with and against the features.
i.e. A routine that really does need to 'create' 1E+6 Objects. In C you can alloc and malloc on demand, but in java you have to deal with the GC. Thus you can give either help the GC out by nullifing obejct refs after use so the GC's scope and refrences scans are quicker or better yet, use an ObjectPool. It's all about optimizing the 10% of the code that does 90% of the work. But PHB bitch about performance when they insist on RAD tools. (Have you ever analyzed the shit code that JBuilder produces??)
There's a hunderd ways to skin a cat, but 90% of those ways are still going to leave fur on the little guy.
Re:Java Question. - Some Answers (Score:4, Interesting)
The richness of a language's vocabulary is what lets its speakers express themselves in powerful ways distinct from what other language speakers can do. French has a number of terms and concepts that don't have direct translations in English, and in fact, a huge amount of common English vocabulary comes from French.
A programming language's libraries are equivalent to a natural language's vocabulary. And this is exactly where Java shines the most from an application development point of view. (It shines for other reasons on other fronts, like for embedded programming.)
Sure, you can go out and develop a C++ app without using pointers, but that's just one app. The next one probably will use pointers. Even if I become a C++ programmer and refuse to use pointers in all my applications, I will have to work with someone who does, or use a library that requires them (is there one that doesn't?). And, eventually, I'll have to maintain someone's code that uses pointers. In the end, there's no getting away from it. Java eliminates the vulnerability pointers represent unilaterally, for better or worse.And similarly, you can go grab a library for doing garbage collection, but which one? You have nearly infinite choices, and every app will make a different choice. It's exactly the consistency of features that make Java superior in this regard. And when I say superior, I mean cheaper, and not just in terms of money, but in terms of resources. The support engineer trying to fix a bug in a Java program won't have any questions about the subtleties of a garbage collection API he's never seen, nor wonder what's in this odd little pointer that seems to keep causing a production crash. These are real advantages, even if they are hard to quantify.
That's just the limit of your experience then. My experience is exactly the opposite. The advantage here is the fact that you maintain a single codebase--the same source files--for all platforms, and they do work as advertised minus any VM bugs (which are fairly rare compared to application bugs).Let me tell you a story. I used to work for one of the real success stories of the dot-com era. My company implemented different pieces of its product using Java and C++, and these pieces used CORBA to interoperate. As far as any one distributed object was concerned, the object on the other end could be any language; it was only a difference of implementation.
Anyway, the support and maintenance costs for the Java portion of the product were dramatically lower than for the C++ portions. They both used the same infrastructure, but one was cheaper and faster to develop in, easier to fix and enhance for the next version, easier to debug both in-house and in the field, and more stable to boot. Add to this the fact that you only had one copy of the source files for the Java portions, versus the several versions for all the different platforms we supported in C++. In the end, if you work on large, complex software systems, Java is vastly easier to maintain, and vastly cheaper to support. Ask any of the product engineers and they would say the same thing: Java is just more pleasant and productive to work in, and they prefer Java over C++. They all hated the C++ portions of the product, and regretted ever putting them in.
And, sadly, most programmers out there aren't that good. With C++, you give them a loaded weapon and tell them to be careful. As often as not, they inadvertantly shoot you or themselves. At least with Java, poor programmers have to load the gun before they can shoot anyone. Sorry for the extended analogy.
Ugh, so much to say here. The problem is that what you are suggesting is a myth; it does not represent the real world of enterprise application development. You don't know your platform, it is not a constant in the equation. You want to provide for all platforms if you're a software vendor. Once you can sell to one, using Java, you can sell to all others without any significant extra effort. Furthermore, bugs fixed in one version of your code are fixed in all versions--support costs go down dramatically.If you're a client, you may find that you are grossly unsatisified with vendor X's hardware/support/performance and want to switch to using a solution by vendor Y (and this happens all the time in the corporate environment). What do you do now? Just because you know things are changing doesn't make the cost of changing any less. However, the fact that you wrote your application in Java does make the cost less--it makes it nil, because the same code runs on HP, Solaris, Intel, Windows, Linux, MacOS, AS/400, etc. The ability to move code effortlessly between platforms allows you as a company to save costs if it makes sense to switch hardware platforms, or mix and match platforms.
Yes, but the application code your GUI fronts is also cross-platform. Not so with the others. And again, there's the benefit of the single binary versus a binary per platform. That's fine, but it really is. Try it. The limited complexity of the language lets programmers focus on the task at hand far more easily in my experience, and it's much easier to do OO in Java than in C++. This means all the benefits of OO are more easily achievable (and if you don't think OO is a good thing, don't bother talking to me.) If you can, great, but I haven't found that language yet. It might be Smalltalk, or Perl, or COBOL, but nothing so far has taken all the great ideas from all of these languages and made them so eminently useful and practical. For example, Smalltalk is probably the most elegant, most forward-thinking languages around (even today), with tons of powerful features. However, it doesn't have the network orientation that Java does, or the C/C++ like syntax that makes it easy for developers to learn. It doesn't have the ability to be pared down and run inside a DIMM-sized computer, or be as dynamic as Java.I'm not advocating Java over other languages if those languages are more suited to the job. I'm not going to write a device driver in Java. I'm suggesting that a task that can be equally accomplished in Java and some other language will be more maintainable, cost less to support, and completed more quickly, when written in Java. The real-world merits of Java are that it reduces resource costs for anyone using it, end of story.
Re:Java for servers (Score:4, Interesting)
I agree with your points, mostly. The company I work for has a TON of function implemented on Websphere running on AIX. We really haven't cared too much about cross-platform features (do a bit of sharing between NT PC apps and Websphere AIX). We were an early adopter of Java because it seemed to address a lot of issues we had in developing C++ and Smalltalk apps (e.g. packaging, garbage collection, change mgmt, etc.).
However, we are planning to move our Websphere AIX implementation (for EJBs anyways) to an IBM390 box (or Z Series these days I guess) and we've found the proof-of-concept effort easier than we anticipated - simply because we can pickup our code (in JARs) and run it on big iron. Very nice! It also gives us some encouragement that we can really start to share more Java classes/components between browser-delivery and fat-client environments if we're smart about it.
Anyways, just one experience that's worked out...
Hype (Score:1, Interesting)
1.) You HAVE TO PAY FOR A DECENT JVM. Ever try running a "mission critical" app on the reference implementation? Take that one to your boss and see what he/she says.
2.) Decent JVM, we use the INDUSTRY STANDARD from a company which I won't name outright (here's a hint, starts with a B, ends with an A and has three letters). It blows chunks, this thing devours memory, we have to RESTART our software servers after 2-3 days uptime. We've had countless patches from this company and none have fixed the memory leaks.
3.) CPU hog.
4.) Memory hog.
To summarize and make it crystal clear to the management types that may have stumbled onto this site. You want to SAVE MONEY, stop buying into the hype unless you like paying outrageous maintenance fees to companies that have NO INTENTION of supporting you. Stop using a bloated hog like java as your standard development language when you can build far leaner and Orders of Magnitude faster code in C. You want better code done in less time, you gotta pay for real developers baby and that in a nutshell is why you have gone to java, you don't wanna pay. In the end, those companies that invest in talent tend to kick ass while those that invest in fadish tools tend to die off rather quickly.
Re:Welcome to FDPR (Score:2, Interesting)
There is one thing wrong with this process; rebuild. The latest generation of Java dynamic compilation/optimization does its work behind the scenes and happens automatically which I think is a huge advantage over FDPR. It allows the optimizer to adapt to unforseen changes in the production environment.
I think that Hotspot-style dynamic optimization is the future of Java and will eventually overtake statically compiled (or repeatedly compiled) options.
However, Hotspot has a lot to learn from FDPR, like how to keep track of performance metrics across VM sessions. The biggest drawback of current Java dynamic optimizers is that you only get their full potential for long-running processes. Once they get optimization profile management down, the dynamic optimizers like Hotspot are going to look much more appealing on the types of benchmarks like this article uses.