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."
This discussion has been archived.
No new comments can be posted.
Java Native Compilation Examined
Related Links Top of the: day, week, month.
On the eighth day, God created FORTRAN.
Well gee *that* makes sense.... (Score:2, Insightful)
Re:Well gee *that* makes sense.... (Score:2, Informative)
Huh? You still have the Java source
Re:Well gee *that* makes sense.... (Score:4, Insightful)
Well, yes and no. There are some very slick Vms out there, and some very lazy compilers, though in most cases, you are correct, native code will execute faster than interpreted code.
The disk requierments, though, can in the long run be larger for native code apps. The VMs have a lot of common tools (i.e. all of the java.* classes) available for any app that needs them. If you plan to compile to native code, you hav to link these in. You can save space by only linking in the libraries you need, but will still end up loosing space when you start installing mulitple applications that all include the SWING packages.
I have been a bog fan of Java for some time, but the need for a VM held me back from a full-out endorsement for some time...it seemed like I was writing toy code because I needed another program to do anything with it, and I didn't like leaving all of those class files laying around. I have gotten over a lot of this, especially once I learned how to make an executable JAR file, and considering the widespread use of DLLs. Plus, I realy like being able to work on my text editor on my home WinXP box, and take it in and use it on our Sun achines.
Still, I'm downloading one of those compilers right now. Why? Because native Java would just be neat. I probably won't even use it that much, but it will be nice to see that it can be done.
Toshiba going mobile with ARM chip (Score:2, Informative)
Re:Well gee *that* makes sense.... (Score:2)
Re:Well gee *that* makes sense.... (Score:5, Informative)
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.
Re:Well gee *that* makes sense.... (Score:3, Insightful)
It seems to me that most discussions of Java lose track of that fact that the key to the "write once run anywhere" idea is that the Java source code is translated to bytecodes and then executed in a non-ambiguous way. In other words, the language definition doesn't have all the "implementation defined" behavior that C/C++ language definitions have.
It takes a lot of discipline to write truly portable C/C++ source code. It seems a lot easier to achieve this source code portability with Java. I think having bytecode portability is a big plus in some cases but not very important in others.
So there's many ways to execute a given set of byte codes - strict interpretation, JIT compilation, native compilation, etc. This flexibility seems pretty good to me.
Java for servers (Score:2, Insightful)
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...
Re:Well gee *that* makes sense.... (Score:4, Informative)
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.
Re:Well gee *that* makes sense.... (Score:3, Informative)
I haven't had a single cross platform problem, the one component written in Perl/Tk has caused no end of grief though.
Re:Well gee *that* makes sense.... (Score:3, Insightful)
What you do in that case is pull the source code out of source control and recompile for the new platform.
100% source code compatibility between platforms is insanely useful. 100% binary code compatibility between platforms, while nice, is not nearly as big of a deal for most systems... As long as you can easily recompile the original source and it runs the same, why not go for the extra efficienty of native if you dont need things like extensive runtime typing (reflection, etc)?
100% right! (Score:4, Insightful)
It didn't work out. Client side Java is essentially dead. "Death to Java applets!" C#/.Net will become what Java only dreamed it could be -- but, sadly, only on Windows.
In the meantime, Java hit pay dirt on the server, because the language is so easy and productive to work in and the result is so portable.
Source portability would have been sufficient on the server, though. I can't prove it, but I strongly suspect they could have created a better server-side programming language if they had designed for 100% *source* portability, then instead of constraining themselves to binary portability and security sufficient for running *anybody's* binaries on *anybody's* client, had instead optimized for high performance plus ease of rapid, bug-free development -- more like Eiffel.
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?
What about Java's safety advantages? (Score:3, Interesting)
Re:What about Java's safety advantages? (Score:2)
Diagnostic tools can be somewhat thin on the ground, which makes it potentially more difficult to diagnose problems that occur in natively compiled Java apps (particularly if the error doesn't occur in the Java bytecode version!)
Finally! (Score:2)
either embed the jvm or the compiler - you choose (Score:2)
Why do people complain about the size of the JVM? Every scripting language has to have the equivalent in the form of an interpreter. The *base* perl installation on Linux is 21MB. That's without docs and a UI toolkit (Java includes both). I don't hear complaints about the size of Perl's interpreter or the heft of the Tk or Gtk toolkit libraries.
Would people like Java more if it didn't have byte codes? If we had a Java shell like Perl, Tcl and Python? Skip the byte codes and let it be tokenized each and every time? Or is it just the cross-platform talk that rankles everyone? Maybe it's Sun's stupid open/not-open antics. Or perhaps it's just language l33t1sm.
Re:Finally! (Score:2)
Check out the Boehm conservative collector and read what Hans Boehm has to say on the subject. I think he qualifies as an expert, since he is a mind behind both the Boehm collector (free beer and speech) and the Great Circle collector (proprietary).
Not new ... ho hum (Score:5, Insightful)
Mind you I noticed in the IBM article that the memory footprint was much smaller. That might be nice.
AWT support a must (Score:5, Insightful)
That's the real shame of the matter. Java shines most in its ease-of-use for creating complex GUIs -- unfortunately that's also where the worst memory/performance problems appear. For instance, Swing is good for client apps if you can ship with minimum RAM requirements of 64+ mb (and even that's cutting it close). Performance is most important in the UI, where the user notices any lack of responsiveness. Hopefully some Java native compilers will help out here.
Different compilers support differing levels of class library; Excelsior JET is one compiler that claims to completely support AWT and Swing.
Maybe there's hope yet!
Re:AWT support a must (Score:4, Informative)
Re:AWT support a must (Score:2)
Do you know if they plan to provide 1.4 support anytime soon ?
One more rant :) (Score:2, Informative)
With Sun's latest JDK, behavior is different between Linux and Windows, despite it being the same version and from the same vendor.
Example:
Under windows: Component gets both Key and Mouse events, as well as repaints.
Under linux: Component gets key event, but frame traps mouse event. And frame traps repaint as well.
You would think they would have the same behavior... This really makes for write once, debug everywhere.
Benchmarks (Score:3, Interesting)
Re:Benchmarks (Score:2)
and string processing too! It's a well-known performance handicap for java. SUN is heading the right direction to improve the performance of it in each version, I wonder how well IBM would perform in this battle?
Re:Benchmarks (Score:2, Informative)
Osvaldo Pinali Doederlein.
The Java Performance Report - Part IV: Static Compilers, and More. August, 2001 [javalobby.org]
The Java Performance Report is an independent study of Java performance, where both virtual machines and static compilers are evaluated. Part IV compares Excelsior JET and two other static compilers with Sun's HotSpot Server VM.
Volano, LLC.
The Volano Report. Dec 26, 2001 [volano.com]
The Volano Report covers VolanoMark(tm) - a widely recognized pure Java server benchmark characterized by long-lasting network connections and high thread counts. This report includes Excelsior JET a native compiler.
Excelsior JET Benchmarks [excelsior-usa.com]
From Caffeine and SPECJVM through XML Transformations to Java2Demo and VolanoMark.
Speed isn't the advantage of GCJ (Score:2, Insightful)
Speed improvements very noticeable in PDAs (Score:5, Informative)
and also http://www.superwaba.org for info on the related JVM for PDAs that it replaces.
Good stuff.
Garbage Collection Question (Score:3, Interesting)
Re:Garbage Collection Question (Score:3, Informative)
Bruce Eckel explains some different approaches to GC, pros and cons, etc., especially as it relates to Java. Check out Thinking In Java 2nd Edition, pp. 207-219. You can download it here [mindview.net].
Re:Garbage Collection Question (Score:2)
Re:Garbage Collection Question (Score:3, Informative)
A good source for starting to address all of your garbage collection questions is Jones & Lins' book, Garbage Collection : Algorithms for Automatic Dynamic Memory Management. Another good source is The Memory Management Reference [memorymanagement.org]
AmigaDE, Savaje, Symbian and Jeode (Score:3, Interesting)
Another weak study... (Score:5, Insightful)
This has to be the third or fourth weak study of Java performance I've seen over several years. Issues such as whether or not all Java features are in place in the native compilations (e.g. array bound checking, but note that GCJ turns this on by default) or what sort of optimizations are performed by the native compiler and JVMs are completely ignored. The author also suggests that compiling from bytecode to native code is the natural route when it's quite possible that gains could be made by compiling directly from source to native. 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.
When comparing disk space, the author comments that an installed JVM can be up to 50 MB vs. 3 MB or so for libgcj. This is a ridiculous comparison since those directories probably include all of the tools, examples and libraries, and as far as I know, libgcj doesn't include the whole J2SE API set, so it's nowhere near a fair comparison. It's a pretty limited set of benchmarks for making these judgements too.
I played around with native compilation of Java a few years ago. At one point (probably around 1996/7?) native compilers could offer noticable gains over Sun's JVM on a numerically intensive application (neural network stuff). However, after the initial versions of HotSpot and IBM's JIT, I couldn't find a native compiler that gave competitive performance on similar apps. I think this is largely due to underdeveloped native compilers with poor optimization (HotSpot is quite insane in its runtime optimizations).
Anyway, I sure hope IBM doesn't pay too generously for studies this poor. Its final message is essentially "who knows?" - not terribly useful.
Alea
Re:Another weak study... (Score:4, Informative)
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.
Re:Another weak study... (Score:2)
All you say is true, however it is merely a flaw in the current GCJ implementation.
A completely optimizating compiler solves the halting problem as a side effect. Hence, any real compiler has places where it can optimize better.
There are only so many compiler writers working on GCJ and many improvements that can made. IMO, the normal mode of GCJ is feeding your own source to it, so their time could be better spent improving the libraries and overall optimization rather then something that's more flashy than useful.
beos developers.. (Score:2)
New name... (Score:2, Funny)
In other news, they have also decided on a name for this wonderful new technology: C.
Re:New name... (Score:2)
Re:New name... (Score:2)
VM: a definition (Score:5, Informative)
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 [symantec.com]. 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 [sun.com]. 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.
Re:VM: a definition (Score:2)
Where did you pull this assertion out? It's rubbish. Eiffel and Ada are garbage collected out of the box. C and C++ can be by just linking code to a different library. The 'V' in VM stands for Virtual. There is no virtual machine being used, it is using the real machine. Real registers, real opcodes. In fact, gcj compiles down to what amounts to C++ (the object layout is the same)
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.
Partly true on both counts. A VM has some known constraints that lends utsekf to optimization. Pointers in C and C++ for example create potential aliasing problems that just don't exist in Java. However, a good native compiler (not a merely adequate one like gcc) can do instruction ordering that a VM cannot. Bytecode has advantages like portability, and with clever classloaders, you can do all kinds of wizardry to objects by rewriting the bytecode. Not every app needs these features however, and so native compilation is also a compelling option. Native compilation also gains you the capability of using more native features efficiently. Case in point, JNI is slow -- Macromedia Generator is largely a Java scaffold around C++ components, so it uses JNI extensively. Turns out to be slower than an alternative written in pure java.
Re:VM: a definition (Score:2)
Welcome to FDPR (Score:2)
Some VM implementations use a sophisticated comprimize between interpreters and JIT compilers [sun.com]. 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.
Err - but you can do that with C++. Ever heard of Feedback Directed Program Restructuring (FDPR)? You run your code under whatever load you feel like optimizing and use the FDPR tools to rebuild the code, changing the ordering and ensuring that cache misses are minimized as much as possible. Try taking a look here [ibm.com] for some more details.
Cheers,
Toby Haynes
Re:VM: a definition (Score:2)
Re:VM: a definition (Score:2)
While profile-driven optimizing compiler are interesting, I think you're missing the point here. With a profiling JIT, the information is gathered and used at runtime, not compile time. That means that you're optimizing for THIS run, not some run that you hoped was representative at development time.
For a bogus benchmark, the two approaches are effectively identical -- each benchmark run presumably runs exactly the same code as the last. The compile-time profiler would win simply because it doesn't add any runtime overhead. In an interactive application, say GUI or a game, you can't really predict what functionality any particular user will stress.
Of course, for added fun, the two approaches don't have to be mutually exclusive. There's no reason you can't find and improve many of your code's hot spots at development time, and then let the JIT do its thing at runtime.
Disappointing showing for GCJ (Score:2)
I wonder how the commercial compilers would compare?
-Mark
The article misses some key points (Score:5, Informative)
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 [qnx.com]), 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.
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.)
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:The article misses some key points (Score:2)
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.
Oh man, you are not kidding. One department at the shop I work at holds their source code very close to their chest. It is easier to JAD [tripod.com] the class files into java code than it is to go through channels to get a copy of the source. Try it - even on big commercial code like an app server. You will be shocked.
Fat-binary? (Score:2)
I also realized that native compilation would destroy the cross-platform capabilities of Java. So I always thought it would be cool to distribute Java apps with both native compiled code for a specific platform and Java bytecode too. That way if you happened to be running the target platform you could get the speedup. If not you could still run the app, and maybe even compile the bytecode to a native app for your platform. This is similar to the fat-binary idea that Macs used when they switched from 68k chips to PPC, allowing a binary to run on either platform.
My Cynical Take on This: (Score:5, Insightful)
As an aside; I see people call Java "painfully slow," but in my experience it's not that painful post 1.3. I'm not giving you benchmarks, and anti-Java people will just "no" me, but these are my experiences after a few hundred thousand lines of Java code over the past few years. Anyway, it's a good exercise to ask naysayers what _their_ basis is; they often have none.
Also, as other posters have pointed out, the speed loss must be seen in the runtime safety context, as bounds checking and garbage collection yield stability and security dividends and, at the end of the day, we almost always want those things and are willing to wait the extra few ms for the guarantees.
All these complaints about speed are especially ironic given how many massive wasters there are in the modern computer, _especially_ in Windows NT/2k/XP.
But the biggest flaw in this Java vs. C debate is that often you don't get a choice between writing code in Java vs. C/C++, since you don't have the extra 50% in your time budget to do C/C++, and your real choice is between Java and VBScript...
All the people shouting "I can write C++ 10 times as fast as you can write Java, loser" please form a line in an orderly fashion, you will be spanked in the order you arrive...
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++.
Different tools for different tasks (Score:4, Insightful)
For ease of coding, I find that Java simply outshines C++ because it doesn't leave me dealing with low level stuff, like pointers.
An occasional big time-killer with C++ is trying to debug something that corrupts memory.This doesn't happen with Java (although you can muck up the synchronization with threading and get unpredictable results which is just about as bad).
On the other hand, if I want performance (such as writing image processing software), I'll go with C++ (or assembler), as there is no way that Java can compete on speed for low level stuff.
And even the awful C++ templates are better than no templates at all.
Re:My Cynical Take on This: (Score:5, Informative)
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++.Re:My Cynical Take on This: (Score:2)
Re:My Cynical Take on This: (Score:3, Informative)
Ummm, you might want to check your facts on that one.
Of course, you didn't hear about it here, since slashdot refused my story. I guess the release of a brand new API the largest software company in the world has been working on for years isn't "news for nerds". Download the runtime/compiler here [microsoft.com] or the full sdk here [microsoft.com]
Re:My Cynical Take on This: (Score:2, Insightful)
Actually I do know. Whatever tool someone last used is what they consider the best tool for the job, especially when they don't have experience with lots of different tools. It takes intellectual honesty to admit that your favorite tool isn't always the best tool for the job, and it takes a fair amount of experience and detachment to reach that point.
Re:My Cynical Take on This: (Score:2)
Oh, and by the way, when I used to bill (I left the loser consulting lifestyle behind long ago), I billed $10,000/week for enterprise Java expertise. You do the long division.
Re:My Cynical Take on This: (Score:2, Informative)
Hmm. Do you include debugging and maintenance as part of development? I'm sure you can type C++ about as fast as you can Java, but the work doesn't end there. One of Java's advantages is the vast reduction of memory leaks (not elimination, some guys can leak resources in any language...). In my opinion memory mismanagement is largely responsible for the typical C/C++ bug.
Re:My Cynical Take on This: (Score:2, Insightful)
If you want to use templates as well as garbage collection, you might like Managed C++ [gotdotnet.com], the
It'll let you code in C++ (with templates etc) but also use garbage collected arrays etc, and the
Re:My Cynical Take on This: (Score:2)
(Mind you, these all compile to separate class files)
Third that! (Score:2)
The biggest speed issues in Java are not from the JVM being an interpreter or JIT, they are from the API and the very high level of safety guarantees provided by Java.
Java code can be very fast, but you have to take the API and the nature of Java into account in your design. If you want to do nothing but sling strings around, you're going to pay a massive penalty for doing it in Java, because all of the Java API's (at least in 1.3 and prior) require String objects for any string activity, and String objects are non-mutable due to a concern for thread safe API calls. If you want to change the third character in a String, you get to either create a new String with that change in place, or you get to create a StringBuffer class that will spew non-mutable String copies for each time you want to use the characters in your StringBuffer.
A C program would never ever do things this way, and so you get insanely better performance. But if you write a C++ program that does do things this way, you'll actually get performance that is very close to Java's, except you have no guarantees as to the integrity of any of your objects because some random piece of code can scribble all over anything it wants to. Plus no universal set of exception classes that everything knows about, no portable thread synchronization primitives, etc., etc., etc.
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
I'm the biggest expert here, listen to me! (Score:5, Insightful)
Some experts who have never used Java want to tell me that it's no good, and will never be any good--why? They don't know, but they know!
And some experts who want to tell me all about why Java's compilation, why it is hard or easy even though they really don't know anything about a compiler.
And some experts on Java's market share who really don't know anything about who uses Java.
And some experts who sat in a room where Java was... gosh gee... being implemented, telling me... well I don't quite know what, but gosh!
So many experts here--I must be reading slashdot!
Hold on. (Score:3, Informative)
The author chimes in, BTW.
Re:Hold on. (Score:2)
A quick scan seemed to indicate that Sun's HotSpot, IBM's JVM and GCJ all do very well.
Bad review (Score:5, Insightful)
-
for
(long test=2; test < i; test++)
If the compiler generates slow code for that, something is very wrong in the compiler.{ if (i%test == 0) { return false; }
}
On the safety front, subscript checking is almost free if done right. Subscript checking can usually be hoisted out of loops. Old studies on Pascal optimization showed that 95% of subscript checks can be optimized out at compile time without loss of safety. GCC, though, being a C compiler at heart, isn't likely to know how to do that. Merely putting a Java front end on it doesn't make it a Java compiler deep inside.
Re:Bad review (Score:2)
for (long test=2; test < i; test++)
{ if (i%test == 0) { return false; }
}
If the compiler generates slow code for that, something is very wrong in the compiler.
According to this message [gnu.org] to the GCJ mailing list, it's because GCJ doesn't produce particularly good 64-bit integer math code..
Re:Bad review (Score:2)
Java version: 51250 ms
C version: 6392 ms
C version compiled with G++: 6412 ms
If GCJ can approach even half the performance of G++ in the future it looks like it'll be a complete win over Javac. As I understand it, Apple's version of Java is quite good, but the two just don't compare.
Re:Bad review (Score:2)
BTW, I would expect that gcj-compiled Java applications start much more quickly than entire VMs. The comparison doesn't seem to take this into account.
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.
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.
Free Java Performance Book (Score:2, Informative)
http://java.sun.com/docs/books/performance/ [sun.com]
-Steve
Excelsior JET (Score:2, Insightful)
It took forever to compile, but once it was done, I had a (large) executable for my native platform, windows.
It ran about 30% slower than the JDK. There are a number of things that are still pretty slow in java, but in general, it's a pretty fast language these days. JIT compilers and hotspot to a good job. It can never be as fast as C++ due to things such as GC, but the performance tends to be close for most applications.
This is indeed interesting, but I think it is entirely irrelevant. Speed of execution is usually about 7th on the list of important-stuff-im-thinking-about when choosing a language and starting a project. There are so many more important things, such as maintainability, scalability, code reusability, code robustness (the number of stuff you get so easy compared to C++ just leaves you wondering how you could ever program in C++ again), you know the stuff. These things are often far more of an issue than raw performance. Look at Slashdot, it's written in perl, presumably because they thought it was easier to write the website in, not because it was the fastest thing around.
Some gcj facts (Score:3, Informative)
Eeent! Sorry. Next, please. (Score:2)
WHEN are we going to get over these Enterprise Application Beanie Stick-Some-Code-In-An-Amorphous-Cloud-And-Forgett
I've done *a lot* of Java programming and I am very disappointed (no, I am pissed!) with the direction Sun, IBM, and the Others are taking the Java language. They have surrounded it with it's own little economy and marketed it to the point were clients instist on using some bloated J2EE Super Servlet Slinger (read drooler) when all you need is like
env | $JAVA_HOME/bin/java -cp $CLASSPATH proj.CgiMain $CGI_PROPERTIES
and a couple of utility funtions.
Native compliers are not going to solve this problem. Java code is just inherently bloated. If you just wrote Java code like you would C we wouldn't be having the conversation. Instead, some jackass has to throw a DB thread pool that doubles as a major object sink for an app that gets 20 hits an hour.
The problem here is that Java is much more forgiving than other languages. But it doesn't relinkquish the developer from choosing proper datastructures and algorithms. I think I should become a DBA. That's were the heavy lifting should be done anyway.
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.
Why the big P-code obsession? (Score:2, Troll)
Hasn't the world realised that java bytecode is yet another attempt to re-write the p-code system of old?
lies, damn lies, and benchmarks (Score:2, Insightful)
I expected a little better from their 'developerworks' people---this is just marketing drivel.
Re:Oh, it's there, alright (Score:2)
Re:What happened to Sun's Java chips? (Score:3, Interesting)
Go here [ibutton.com] for more info.
Re:It's about time! (Score:3, Informative)
Man, JAVA to native compilers exist since 1996 or even earlyer.
Symantec Visual CAFE did it from the first release.
If you enter "+java +native +code +compiler" into altavista.com, yahoo.com etc., you find at least 20 solutions providing that.
The problem is: a java application on linux is no longer able to communicate via RMI or object serialization etc. with an other java application on Solaris or any other OS. You loose reflection support and similar low level access to the runtime environment.
Its a common myth that java is (to)slow
There is even a GNU implementation of a java to native code compiler, since
---> gjc
Regards,
angel'o'sphre
Re:It's about time! (Score:3, Insightful)
Re:It's about time! (Score:2, Insightful)
Are operator overloads misused? Sure. So are knives, but that doesn't mean that cooks shouldn't use knives.
But you wanna talk about language features that Java lacks? How about enums? Why leave those out? And whats with this whole "bean" concept? Why can't that be a first class concept with real syntactical support instead of this asinine get___ set___ crap?
I could be biased, though.
Re:It's about time! (Score:2, Insightful)
Of course they can..and that person would be a goddamn fool.
The point is that an operator overload might make complete sense to the person that programmed it. The next person who looked at it may have used a different convention and interprets it differently.
As an example, I overload (file--) to delete the file. But the convention you read in the latest issue of 'L33T Developer' indicates that (file--) should mean close the file handle. You look at the code, make somes changes and your clients file was just deleted.
And BTW, I would never have called a function that deleted a file
Jason.
Re:It's about time! (Score:2, Informative)
Here you go. [winternet.com]
What's etc?
niko
Re:Java's Cover (Score:2)
If your programming mucks up, the wrong people DIE. If you don't have standards that are _rigorously_ abided by, our soldiers DIE. The US military and the rest of the gov't prides itself on it's technological edge. It relies on on structures that are there NOT to screw up (ask a space shuttle computer programmer about standards sometime).
At the risk of responding to a troll, I'd like to point out to the parent's moderators that there's a reason for "bureaucratic" programming.
Probably the reason the DoD likes Java (if they do, I don't know for sure) is that it's well documented, has a wealth of libraries, and reasonably safe (secure) out of the box, even in the hands of someone relatively inexperienced with secure coding standards.
To get back on topic, I've tried native compilation of Java code...I'm not really sold on it. On higher-end machines, or machines with goodly amounts of ram, Java's no stinker. The upcoming 1.4 from Sun promises neat stuff like 2D acceleration. No 2D accel is one of the reasons why redraws feel relatively slow now. Plus, speeds of JIT's are increasing to the point at which I'm not sure I'd want to give up platform independence. If anything, this is probably useful to the handheld crowd, more than any other platform.
Re:Java's Cover (Score:2)
I didn't bother reading your discussion of why you don't think Java will be a very successful language (too late, by the way - it already is), but I have a hunch that all of your points were invalid.
Re:Java's Cover (Score:2, Flamebait)
Small list of open-source Java projects:
There's quite a community based around Java - I would suggest people start looking at those aspects of its cover.
Re:Java's Cover (Score:3, Insightful)
I agree with you relative to C/C++, and I was using Java heavily a couple of years ago. But now I've moved on to higher-level languages such as Perl, Python and Ruby. They each have APIs that provide functionality similar to Java, but usually simpler and more intuitive. They also don't have licensing policies or agendas driven by one particular corporation..
I usually get the same job done with 1/2 or 1/3 the lines of code as with Java. I've also found that once you free your mind from the strong-typing yoke, you can transform your concepts into reality much more efficiently.
It's funny that a few years ago I had to argue to the PHBs that Java was a valid solution. Now, they are set on Java, and I have to argue that a better solution has emerged as support for other languages has matured.
Re:Java's Cover (Score:3, Insightful)
Re:Some thoughts... (Score:2)
Hmmm.. It would seem to me that some run-time dynamic binding features present in a JVM would be lost in a native code compilation.
Re:Some thoughts... (Score:2)
Re:Some thoughts... (Score:2)
Re:what about compile time speed. (Score:2)
For me the most painful part of java development had always been the compiles. Sitting there, waiting minutes for larger projects until everything was done. With jikes that now takes seconds. I really don't even want to think about the hours of my life that are missing from just waiting for javac...
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:prime example rewriten in C++ results (Score:2, Informative)
Change the Java code to use "int" or the C++ to use "long long" for a fairer comparison.