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)
What's the point of taking a language that jumps through hoops to be "cross-platform" and cutting it's legs off?
I was waiting for this to happen. The two things between Java and me are non-native code and some OOP problems (no operator overloads, etc). It's good to see new work being done on the VM side of things. Now I have to consider JSP as a possibility -- good good good!
Mike.
http://www.yourmothernaked.com
Runtime bounds checking, typecast checking, etc... do those get included in the native executable as well (and if so, then wouldn't the performance hit negate the advantages gained thru native compilation?), and if not, then it could be dangerous.
There's 10 types of people in this world, those who understand binary and those who don't.
I've seen a few php 'compilers' that do the same thing. They basically jam the executable and the script together in a self extractor, and let them sort themselves out... slowly.
On the AS400 you can run your jars through a compilation process. Whenever the jar is referenced by the system the compiled code is picked up and run. We haven't seen particularly performance improvements from this, but I guess it depends on the sort of work your code is doing...
This would solve my greatest beef with Java - that messy JVM which piles into the processor when it compiles bytecode. Of course, the idea of running Java natively seems to defeat the purpose of Java entirely: runs the same on any computer. Interesting idea, though...
political_news.c: warning: comparison is always true due to limited range of data type
If the code is in native binary form and not bytecode, I guess it would make it harder to reverse engineer. I don't have to run those obfuscation-wares everytime I build. Saves time (both in building and running)
Lets see TowerJ has been out since when ? 1999. Having tried my hand at this I have some reservations. The project I was on ... a large dinosaur of a thing which will remain nameless had 12,000 classes which TowerJ turned into C files which were then compiled by GCC. Resulted in 50 megabyte executables on a Sun. Didn't really solve the problem which wasn't really about speed but throughput. The solution was a better design using servlets and Java Webserver ... result DRAMATICALLY faster without any need for native compilation.
Mind you I noticed in the IBM article that the memory footprint was much smaller. That might be nice.
Bitter and proud of it.
Most notably, there is very little support for AWT, making GCJ unsuitable for GUI applications.
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!
The program used in the benchmarks was very simplistic .. I would rather have seen a program creating and destroying many objects of various sizes. In the nativly compiled version, how does garbage collection work? Is it possible to write AWT apps? Swing?
This is built into the .NET Framework. Run ngen.exe on any .NET .exe or .dll and the MSIL is precompiled into an optimized native binary. In fact, setups for .NET apps can do this on the assemblies they install. Indeed, the .NET Framework actually precompiles its managed shared .dlls on install time.
The big advantage of GCJ isn't speed, it's the vastly better interface to C++ code (CNI vs. JNI). Of course, using that really does make your code non-portable.
I, personally, *resort* to Java only when I'm looking for a level platform-independence that can't be accomplished with Tcl. Is it really worth the hassle to not use an alternative langauge that is more efficient if we're targeting a single platform?
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.
I always thought Java was very interesting with it's cross-platform compatibility and whatnot. But as everyone has noted, it's painfully slow. I always wondered why people hadn't implemented a native-code compiler for it. Sure, with bounds-checking and garbage collection, natively compiled Java will still be slower than natively compiled C++.
The point is, Java is really just another programming language. What's wrong with allowing developers the opportunity to write their natively compiled software in a solid, object-oriented language that doesn't have all the backwards-compatability issues that C/C++ has?
Whether this will be useful, I dunno. But it opens up options, and that's always a good thing.
Learn to Play Go
I don't have to run those obfuscation-wares everytime I build.
Obscurity != security. For every piece of obfuscation-wares, there's an equal and opposite piece of de-obfuscation-warez. Besides, what do you have to hide?
Will I retire or break 10K?
Seems to me the problem with Java is that it waits until memory is full to garbage collect. In C++ Code, if you allocate and free a lot of memory, eventually you are going to fragment your memory to the point where you may not be able to allocate large enough memory blocks for your purpose. GC is supposed to get around that. But if C++ doesn't GC, how can a C++ app run indefinitely. I would really appreciate someone who understands the subtle nuances to explain. If there are better memory allocation schemes, couldn't you use them until you were forced to use GC?
Open Source Identity Management: FreeIPA.org
I was a little disappointed in the selection of the the JVM's they selected for their example. Especially now that PDAs/CellPhones are now powerful enough to run real applications on the client. I have yet to see a StrongArm device ship with the Sun, IBM, or KaffeJVM, why, because they are slow. The JVMs listed in the subject line run 10-200x faster on devices. Soon we will see EJB and other J2EE compents on PDAs. As a developer of client java applications/applets I would never distribute a device specific application, it would be a nightmare to have 160 diiferent compiled versions of the same application. The good JVMs already have done that, and my code I compiled years ago works on the newest PDAs...So there
"Get them before they get....
Dallas Semi makes the TINI, a Java implementation in hardware packaged as a 72-pin SIMM stick. I have one and it's cheap and fun to program. Built-in ethernet, general purpose IO pins, etc.
Go here for more info.
People have been doing something similar to this for years. The original versions of Quick Basic (not QBasic) did just this.
Better yet... up until I believe VB5 (maybe 4 or 6) you HAD to have that vbrunxxx.dll. What do you think THAT was? It was the BASIC intrepreter. I have never liked this and I personally probably never will. But to each his own.
Java could still turn out to be a great platform... but I don't think that by taking away Java's key functionality it will achieve that. If you want something to be compilied natively use C++, or even *gasp* Pascal. C, C++ are close enough (if you use ANSI compliant) to where porting isn't too difficult, and the speed is much better. Java is for the people who NEED to have one app run on any platform. It has its use... it does very well with it. So if it ain't broke......
By the way... I heard rumors a couple years back of a Java OS. Anyone heard anything more about it?
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.
Garbage collection is not by definition slow and is generally the same as new/malloc -- although lots of people seem to think it is alot slower. For non-gui code and if your doing pure Java code (i.e. no JNI) the performence is rougly comparable to C++ (assuming you have a good JVM).
I am not a number! I am a man! And don't you
This has been happening for quite some time. Native code compilation of java is nothing new!.
Derek Greene
when it's set to produce bytecode? If it produces slow bytecode, then it wouldn't be that surprising for it to produce slow native code as well. This could just mean that it's immature and not well optimized. The article would've been more useful if he'd tried out more than the one native compiler, as well, since he lists eight of them.
I'm not going to try to champion Java, JITs, or native compilation, I'm just going to point out what's wrong with this "study".
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
With the renewed interest in beos thanks to the leaked 5.1/dano release, developers for beos should seriously consider trying for a native compiler since the various jvm projects arent going anywhere fast. If beos could run java apps, I could see this renewed interest continue to grow at amazing rates..
"...compiling Java apps to run as native appplications on the target machine without the need for a JVM."
In other news, they have also decided on a name for this wonderful new technology: C.
Simpli - Your source for San Jose dedicated servers and colocation!
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."
Another Thing About The Article:
1995 called. They want their story back, pronto.
If you celebrate Xmas, befriend me (538
You know, I would be a lot more impressed with Jawa bytecode. The label "utinni" would stand for any register- let the computer worry about it. If it was English it would be like saying "move 0x203 over there".
graspee
actually.. limewire does the trick quite well...as much as i hate to admit it.. java has its uses
The war with islam is a war on the beast
The war on terror is a war for peace
re the java OS:
i recall sun sticking a fork in it around 1998
Is it just me or does this article seem like a shameless plug for IBM's JRE? It seems to wil all but two of the tests (and those are regarding memory usage, not so much performance). I'm betting they picked the tests that the IBM JRE would score well on to push their own product, while letting native compilation come in second a lot of the time so it could still be somewhat of a winner. I wouldn't make decisions by these numbers in any case.
Brian
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.
Lasers Controlled Games!
A while back, there was this thing called "C" which already does this. Some say it is faster too, but that's an entirely different dead horse needing little beating.
I've always thought AS/400's native compilation was very cool. The bytecode hangs around for compatibility purposes, and there's a hidden staticly compiled object that the system links to it. You probably haven't noticed a lot of performance benefit from it because you're already using compilation without knowing it (your default optimization level is 30 or higher) or you're using the JIT, which is also screaming these days. Try using optimization level *interpret and you'll see what I mean.
AS/400 can also use WPO (Whole Program Optimization) when creating the program objects... something you can't get in a JIT. However, a good JIT will selectively optimize heavily used pieces of code... something not even the best native compiler can do. However, A native compile with WPO would be hard to beat with almost any program.
I love Java. Whoops, there goes No. 4!
Nice troll. Completely devoid of fact or evidence and you still fill a page. 10/10.
ratty
I found it interesting that this author, an IBM researcher, chose to only test a single java-to-native compiler, the GCJ (GNU product). This is an immature open-source package that I would not expect much performance from. His paper rehashes a lot of really basic info, then gives some performance results which show IBM's JVM spanking Sun, Kaffe, and GCJ. This is no great surprise; IBM is tooting it's own horn - fine, they deserve to IMHO. But as an exercise in "the state of native compilation" it's useless. What would actually be really useful is a comparison that also included at least a half-dozen other major players in the java native compiler market. I suspect you'd see some different results.
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...
We're on the road to Tycho.
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 would but pointers scare me.
Pointers bring droughts to farmers and carry off your daughters!
It's a pretty cool idea, but CPUs don't supply some features that make Java (and other interpreted languages) so cool.
I've had this discussion with a lot of people...
"You can't do [xyz] in C, but you can in [language of choice]."
"Really? What do you think the [language of choice] interpreter is written in?"
Thomas Galvin
Wouldn't a native compiler defeat the whole purpose of Java?
I mean C is fairly portable in the sense that any console mode app will virtually build anywhere.
If they are moving Java to a "machine code" type system how would it improve on C [in ways that C++ didn't?]
Personally I'm a huge C fan, I can appreciate C++ and Java too. But this going full circle crap is just stupid.
Tom
Someday, I'll have a real sig.
I think you're missing something. The one big thing about Java that differentiates it from languages such as C++ is that it is as much as language as an API.
Languages don't really make you more productive. Sure, one Fortran is good for numbers, Assembly is great for performance but they both lack an API as consistent and productive as the Java API.
Programmers building applications for business (web servers, database front end, app servers, etc.) love the idea that we can use a great language and someone (Sun) is going to help define standards, deliver workable (and free) parts and support developers.
The best comparison is Visual Basic. As a language it stinks. As a development environment it rocks. Delphi is a bit better on the language part and Java nailed both.
I've never found a language that allowed me to be as productive as Java for the type of applications that I build. The language supports all the things I need such as threads, network communication (RMI) and web development (JSP) and the API allows me to develop apps quickly and with the freedom of interchanging parts (Web servers, databases, etc.) from different vendors whenever I want.
Jason.
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.
"We apologize for the inconvenience."
I used to have the same beliefs about Java, and I authored quite a bit of software with it. I thought it was klunky, slow and you had to kludge your way through it to get it to work exactly as you wanted. The platform independence seemed mythical, despite all the anecdotal success stories from Sun and Java's creators.
That has changed somewhat. My enterprise backup system uses Java as the administration interface, and it's fairly snappy across Windows and Unix. It still suffers from inconsistencies between platforms, it's still painfully slow in certain functions, but it's come a long way since I programmed in it.
My first two programming languages were both assembly,
:-D
so you know I am a performance freak by nature.
When I first tried java, the only two things that came
between me and it were run time and compile time
speed.
The later has been solved by native compilers, and GHz
speeds.
The first is yet to be solved.
For an edit-compile-run-debug programming language like
java, I need the least time between edit and debug.
The "one public class per file" policy forces some
code modularity, and with an incremental compiler,
speeds things up.
But the java compiler itself is SLOOW. My energy
is exhausted waiting to test the effect of a one line change. Turbo C did thrice that work, on my
286, under an operating system that didn't see more
than 640K bytes, thank you very much.
I am much more productive, evaluating my expressions
immediately in an emacs buffer, and running CLISP
as an inferrior
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.
You are in a maze of twisty little relative jumps, all alike.
Lots of experts here.
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!
Thank you for your uninformed opinion.
Seriously, you tell us you've never used it, but you don't like the look of it? How useful is that?
There's a thread about this article over at the gcj's mailing list: here.
The author chimes in, BTW.
This comment can also be viewed here.
Limewire isn't exactly what I'd call lightweight.
Useful, perhaps, but fleet-of-foot it is not.
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
I wonder what kind of book you get by just looking at the cover. :)
:-)
Some people never learn
Yesterday's cover was nice as well.
Tomorrow's cover will probably be nicer than today's.
If you are a real hacker, you are going to learn everything you can.
Knowledge still is power !
I find that java is either loved or hated.
I think a lot of people hate java because it makes the feel obsolete. In C & C++ you have to do almost everything from scratch. (Manually check array lengths, clean up your memory, build your own utilities classes and functions.) And at the end of the day when the app is done you can say that it is 100% yours. Every machine instruction being executed it yours. This instills a lot of pride in the person who wrote it.
Also C and C++ is cryptic. It's made to be hard to read. It's made to save keystrokes. Again this makes the programmer feel good. Only great programmers can read hit code. Ha!
Java on the other hand has a ton of stuff done for you already. All sorts of goodies built in to every version. And they are available wherever you go! This lets me build more complex applications faster.
Why is Java hyped? Bias, the developers of Java knew that the Hacker culture would reject it because it takes away their security. (Code is easy to read, Time isn't spent building low level classes, easy for someone to pickup where someone else left off. Easy to refractor.) They need to yell louder then the grumbling in the C, C++ community.
Why does business like it? Because they are sick and tired of dealing with cocky programmers who can hold them hostage. Everyone knows a good C, C++ programmer is hard to find. Java takes away a lot of this power, because it's easy to read and learn.
So the last refuge of the C, C++ programmer is speed. They can say there app is slightly faster then Java apps. With computers getting faster every day, this becomes less and less of an argument.
-
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.
Java, in the form of EJBs and servlets, is becoming fairly common on "big iron". One reason is indeed the cross-platformability of it. But, frankly, most often a change in platform accompanies a change in framework. For example, a switch from UNIX servers to a mainframe may accompany a switch from CGIs to an application server (such as Websphere). The dramatic switch here is probably not from UNIX to OS/390 (after all, OS/390 has a POSIX layer), but from CGIs to Websphere. So, as you said, it's not really cross-platformability which is driving Java in the server realm. I think the principal reason is that Java provides (at least some semblance of :) a language-level security model. By security, I don't mean crypto and virii and external attacks. I mean an application is secure from itself, and its (all too human) programmers.
It's being done by IBM, anyone would think it's biased? :)
:)
:/ (We call Kaffe 'MS' JDK'2, not just for humor, but it's really the case. ^_^)
:D
:)
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 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.
Don't worry, you are not really responding to a troll here, and I think you make sense a lot.
Java is good for the fact that, as you say, it is well documented, clean and secure.
But the post here (which is a rant by Paul Graham) is somewhat taken out of context. Paul Graham dislikes Java, but it is because he is a Lisp hacker. Really, he is very good at what he is doing. He is working on a new language too (Arc) which looks very promising.
Paul is used to have a very, very flexible language in his hands that allows him to speak freely to a computer, while Java is more of a rigourous and "straight" language. It does have all the strengths it pretends to have (security, efficiency, portability...) but it lacks some expressivity that you can get in Lisp.
I guess it is a question of audience...
cheers
I have been a java developer for about 5 years. When I first heard of GCJ, I decided to try some informal benchmarking. One area which has sucked with java is IO performance. Sun is addressing this with jdk 1.4, but in a real world business environment, jdk 1.5 will probably been in production before anyone is switching. Anyway... My benchmark consisted of creating a text file of arbitrary length (1024 bytes was the default I think), and I found that IO performance with GCJ was even slower than java IO with the sun jdk. This was about 6-12 months ago, so GCJ may be better now, but at the time, all I could do was laugh. Take something which sucks, and make it suckier is not a way to gain market acceptance. ;)
Most of the programs I write are small, text-based, unix-like applications.
I'd like to use Java because of its garbage collector, string, and exception support. The explicit memory allocation required by C/C++ is annoying (even more so without elegant error handling), and string manipulations are tedious in C.
The problem is that the VM is too bloated for small programs like this. What? I have to load a several megabyte (or more) VM into memory to run a program that's less than 100 KB?
And what if I want to distribute these programs? What? I have to ask users to download and install a several megabyte (or more) VM to use a program that's less than 100 KB?
And then there's the joy of dealing with different VM versions. What fun. Is there any kind of guarantee that future VMs and future libraries will behave the same way as the current ones? If so, backwards compatibility makes them even bigger.
As far as cross-platform issues go, I really don't care. I'd rather cross-compile if necessary, and as long as the source code is portable, that's good enough for me.
As does DE.
Wow, I should not post when knackered.
On the otherhand, companies buy Sun hardware not for pure speed, but for reliability, redundancy and proven scalability. The one thing all these benchmarks fail to address is "how important is speed over reliability and scalability?" A good programmer can take out lots of security, memory management and allocation checks to make it run really fast, but how stable will it be? Will it be solid enough to run 24/7 with 1% downtime? With the way CPU speeds are increasing, who cares about speed. Lets talk about the real issues, ease of development, maintainability of the code, built in document creation, wide selection of prebuilt libraries, consistent and solid security model and portability between platforms. My personal experience, large companies use a variety of platforms, so a windows only solution is not an option. A solution that allows multiple developers on different platforms to build their pieces and integrate is what many large projects require. Doing so with C can be done, but how many people feel C code is easy to maintain? I don't know that question, since I've never coded in C. Those I know who use C joke about how unreadable C becomes. Bottom line, each tool has it's strengths and weaknesses. It's about which problems you want to live with.
One of the best articles on native compilation is this performance report
Also see on Javalobby the The "native compilation" myth and RFEs for JDK1.5 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.
Once again with feeling (sorry I forgot, under deadline):
Jump Project
SuperWaba
Beta only seems to work for Google. Such a shame.
You simply can't run most Java programs without either a JVM or a bundled compiler. The reason for this is dynamic class loading. You can load classes by arbitrary name, from urls, from byte codes you've created on the fly in memory, etc, etc. These classes cannot be precompiled. So you either need a JVM to interpret them, a compiler to compile them, or both in the form of a jitted JVM.
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.
http://java.sun.com/docs/books/performance/
-Steve
The newer SPARCs can do this.
Wow, I should not post when knackered.
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.
dominionrd.blogspot.com - Restaurants on
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.
I agree. As much as I love Java, Swing is definately shit. Well, some of it anyways. Like JTree and JTable... They are very tedious and complex to use. The Tree and Table implementation in C# is much more logical and easier to use. And why is all of java pretty much synchronous, but the image processing stuff asynchronous? That's stupid. They recommend queueing up repaints every 100ms while you draw to the graphics object. But repaint calls update, which clears the graphics object. That means you have to draw the whole damn thing over again. And even if you fix that, what if you are painting in layers. Its screws everything up. So to solve that you use a MediaTracker and paint after the image is done loading. I've seen lots of other people's code, and they do the same... So with that being done, the whole thing might as well have been synchronous, and stick it on a different thread or something, and make it like almost everything else in Java.
And someone earlier said Java network classes are nice... Java network classes suck even more than Swing does. What if I don't want to spawn a thread for fscking everything? What if I want to have access to lower level things that Berkely gives you? Tho, 1.4 may fix that. But what's up with the static cache in the InetAddress.GetByName???? That makes it absolutely worthless, as if you call it to get the IP before you dial-up (for example), then no matter what you do, it will always return 127.0.0.1, likewise if you do it after, then no matter how many times you hang-up re-dial, and get a new IP, it will return the same IP. Or if you are using wireless, and you go out of range and come back, etc etc. Of course, there are undocumented APIs, but relying on those is stupid.
Anyways, I'm done ranting for now...
Why is everything inconsistent?
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.
Perhaps the reason you never get a good answer is because your scepticism about an answer positive to Java is apparent.
This is anecdotal, but programming useful vertex, edge, and graph classes for an AI test took me three hours in Java. It took me three weekends in C++.
The difference lay largely in having no memory management to worry about, and having good container classes and enumerators. It took a long time to get the kinks out the C++ classes (and that was using STL vectors and iterators).
The less complex java syntax made it all straightforward. The more complex C++ syntax had me tripping all over the place, and I've written more C++.
An experienced C++ programmer wouldn't have had the problems I did, but then I'm not an experienced Java programmer, either.
My test was small, so there were no noticeable performance differences on which I can comment.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
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.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
More open-source Java projects at javaindex.org.
Rich
I've used both C++ and Java extensively (although I haven't used garbage collected C++).
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.
You would...Love Java, but poiters scare you?
Be brave, young Incon, for Java has no pointers!
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
- You can learn the C++ classes, but there is only one standard class library: the STL. Not to mention the fact that much of the high-level functionality that exists in Java (e.g. networking) you'd have to implement yourself or get from a third party if you used C++.
- Why reinvent the wheel? Not everyone has the time to go write a garbage collector. Java gives you one. Also, you will never be able to avoid using pointers if you need to use third party class libraries.
- #ifdefs are extremely inelegant and make code maintenance a pain in the ass. Why not just use a language with the knowledge that it will run elsewhere? No more wondering how many bits are in an int on xxx platform.
- I haven't ever used GTK or QT, but why not use the graphical components that are developed and tested by the same people who wrote the language?
- Java the language is quite easy to learn. However, learning the class libraries it has will take some time because there are so many.
- I agree with you here.
The real-world merits are that your development time will be shortened because you won't be buried in syntax, or have to chase pointers around, or have to worry about memory management as much, and much of the higher-level functionality has been thoroughly tested and used by countless others before you because it's part of the standard classes.Now, Java isn't a panacea (games programmers will probably stick with C++ for a while), but I think the reasons I outlined above make it more appealing than C++ for many, many purposes.
Think of just about any application that you might write and imagine the steps toward completing it. At each step consider how long it would take to accomplish that step in Java vs. C++. I think you'd find that C++ would have you finishing it several months after you'd finish it with Java. Not everything is a performance issue.
No JVM for this baby.
A feeling of having made the same mistake before: Deja Foobar
Thank you for your lucid commentary.
1) The better organization (and more sensical naming) are part of what make Java easier to learn, giving the programmer more time to master.
2) How many Joe Programmers do you know that can write their own garbage collector? What if that custom garbage collector has horrible bugs? When you need to write a program quickly and its stability and security are paramount, Java all but eliminates these worries. As far as Lisp and others having garbage collection--yes, that is true, but few programmers know Lisp (other than tweaking a little EMACS). Why is NT so popular for networking? For its merits? (HA!). It's much easier to find an MCSE than a Unix admin--and cheaper. The same goes with Java VS. Lisp, Smalltalk, or even C++.
3) This often isn't that big of a deal, but it is great for the 10% of the time that it is a big deal. As far as browser incompatibilities, sticking with basic Java 1.1 or 1.2 tends to be very safe, but I haven't delved much into that realm.
4) I wouldn't really mention that part if I were asked about the merits of Java, but to Java's credit its GUI libraries are part of the language spec. GTK+ and QT are definitely not part of the C spec, so it is not reasonable to expect a platform that can run C apps (all of them) will be able to run C apps that call GTK+ or QT functions. If you make a button in Java, that button will work simply by virtue of the fact that the platform runs Java. At least in theory...
5) Me too.
6) I know little of Javabeans.
Hope this helps a little.
Note that despite the above, I still prefer C or PERL for almost everything.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
LOL, good argument. In my experience, C can do everything except certain very specific platform dependant things that ONLY assembly can do. What, really, can literally not be done in C that can be done in any other HLL?
Certainly, things can be done more easily, or faster, or more quickly, but as far as a specific programming task that C simply cannot do--I have yet to see one.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
Yes, but where are the word processors, spreadsheets, databases, operating systems and real world applications (i.e. PhotoShop, Quark, Maya), etc. written in Java. Hmm?
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.
The only certainty is entropy.
1) "Java classes are well-organized and well-documented and all-in-one-place." Not a language mertit! You can learn C++ classes as well.
.this article about native Java code is just this. . . .
Yes, of course you can learn C++ classes. However, they don't usually come with the language (for free). Having the Java libraries ensures a certain degree of standardization. I think a lot of Java's strength comes from the bundled libraries (reuse at work...).
2) "Java stops you from your own stupidity by not allowing pointers and has garbage collection."
That's a valid point, I think. An awful lot of hard to find bugs are caused by memory mismanagement. Not to mention all these security holes that allow buffer overflow exploits.
If you REALLY hated pointers that much you could write C++ code without pointers and write your own garbage collector
Writing your own garbage collector ain't all that simple if you want it to be safe and efficient. A lot of research has gone into the Java GC, you don't write something like that on a rainy afternoon.
(not to mention that LISP does garbage collection too -- nothing new).
Sure. The fact that it's nothing new doesn't take away its value, though.
3) "Java is cross-platform." I haven't seen too many implementations when cross-platform is needed at run-time. The browser cross-platform stuff seems to have died in the browser wars and Java incompatibilities in browser implementations, thus most Java developers that I know are making JSPs. You know the platform of your server (it won't randomly change without you knowing) so why not write in a higher-level language such as C++ and skip all the platform-dependant code (or do ifdefs) and have it run natively faster? If your platform changes you just re-compile. .
I agree with you here to a certain degree. Cross-platform often is not needed, and 100% cross-platform rarely happens anyway. Java code is a little easier to port than most languages, but it's more of a convenience than a compelling advantage.
4) "Java has a cross-platform GUI". So is GTK and QT.
Again, that doesn't mean it's not an advantage.
5) "Java is easy to learn". I'll skip that.
Why? I've programmed in about a dozen different languages, and I kind of like Java, without being a zealot about it. In my opinion, Java is indeed somewhat easier to learn than most languages, especially if you come from a C/C++ background. Of course the challenge then is to avoid all you bad C/C++ habits...
6) "Java has javabeans, etc". Not a language merit!
That's basically a repitition of your argument about the libraries. Again, it may not be part of the core language, but it sure can be useful in certain circumstances.
Why program in Java when you can achieve the same result faster in another language?
Ahh, but that is interesting! You say you're not a Java programmer, and yes, in that case programming in a language that you do know will be faster, obviously.
However, I can assure you that developing a solution with Java is generally faster than doing it in, say, C++ (assuming you have roughly the same knowledge of both languages). A large part of this is due to the libraries.
A small example: some time ago I had to write a C program to manipulate an Oracle database. It took me a whole week just to write 1200 lines, mainly because of the horrible API calling conventions. I think I could have done the same thing in half a day , in 100 lines, using Java and the JDBC classes.
Granted, Java is not the optimal solution for all problems. Some string manipulation stuff is probably easier done in Perl (or another language optimized for string manipulation). Every problem has its own optimal solution, but as a general-purpose language, Java is pretty good.
MSN 8: Now Microsoft even has bugs in their ad campaigns.
The only certainty is entropy.
Would you mind to add ArgoUML to your list? Losts of nice folks using Java voluntarily for a big Opensource project. Uses AWT, Swing, etc. and is actually usable! (No, not too slow).
Come out of your cave!
Java is everywhere serverside, there are a lot of companies, websites that use java as jsp or servlets e.d.
On the client-side there are quite a few java-applications too, besides Limewire there are a few IDE's like JBuilder, EClipse and Forte (where the first too are quite fast for ide's too), also, a lot of websites use applets.
With Java-webstart, more java-applications will be introduced, since it'll make client-jvm installation a breeze.
(-% TwistedMind %-)
Sun pushed *binary* compatibility so hard because Java's claim to fame was taking what loaded into your browser from static content to full executable apps -- making the underlying OS irrelevant in the process. "Death to Windows!"
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.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Your C++ version is not comparable. A "long" in Java is 64 bits. A "long" in C++ is 32 bits. The Java code is doing far more work.
Change the Java code to use "int" or the C++ to use "long long" for a fairer comparison.
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 for some more details.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Why doesn't HotSpot have a bin dump of its 'insanely' optimized native code? This way, you have a small and fast native app, and a smaller 'JVM' footprint that supplies the rest of the stuff you don't want natively compiled (like GC thread etc.) Unless I miss something, I'm sure this is technologically achievable on Sun's part, but they're not doing it for political reasons. Do people remember the days of JavaOS and Java chip? When the JVM is part of the OS, you can't call it 'virtual' anymore, and this subtle difference has a psychological effect on people so they will stop complaining about the JRE footprint etc: the JVM process is officially now part of the group of system kernel processes. So then JavaOS becomes a platform by itself and who knows if it will be compatible with any other platforms out there, especially if it starts to gain a significant market share. Just face it: IT business is 99% about market share and locking users in.
www.rexguo.com - Technologist + Designer
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.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
So why aren't you switching? Rates go up as the number of practitioners in the field drops - usually as a result of reduced demand. The last man standing in the C++ practioner market will be a happy camper, but this doesn't indicate a success for the language.
A comparison with C/C++ compiled by gcc. At least for the prime factorization, changing the code from java to C would have been trivial, and would also show any discrepancies between natively-compile java vs. compiled C.
My server
Ajile's AJ-100 and AJ-80 chips implement native Java instruction set. You grab a development board from Systronix . Which means you write your device drivers in Java!
Bah. My beef with java is and always has been that it is slow, buggy, and produces a reliably ugly GUI when you need to create one. It really doesn't matter which platform, either. Apple used to do this advertising (you will laugh) which said "See java run - quickly!" Guess which OS? If you guessed X, you're right. The fact is that for whatever reason (I admit ignorance - I don't know!), Java is slower than other languages. I have been watching this thread, and it is interesting to see the arguments re: automatic garbage collection versus manual cleanup.
My >guess is that the reason most Java apps run so slowly is because the language is structured in such a way that it is easy to write sloppy code. For example, why bother figuring out which specific library to call up when you can just call java.lang.* in your file. In that sense, I guess I am guilty as charged. The second biggest reason most people poo poo Visual Basic is that it lets people get awaw with writing shitty code. Same with Java.
political_news.c: warning: comparison is always true due to limited range of data type
Obviously Java has not turned out to be the universal solution that it was supposed to be. Of course there are non-Java solutions for some problems that are objectively better, or at least preferrable to the developers that employ them.
The purpose of my rant was not to advocate Java in general, or any particular approach to it. (In point of fact, I haven't worked with Java for over 3 years. As I said, I'm no expert, and it doesn't suprise me that people find flaws in my summary of the VM issue.) I was merely pointing out that the naiveness of the VM-versus-Native dichotomy.
Then perhaps you should learn how to use C++.
Not to flame you -- I'm usually the first person to use the right-tools-right-job argument -- but one of the best books to teach C++ doesn't even mention pointers or builtin arrays until chapter 10. They teach C++, not C features that happen to show up in C++.
After having used C++ quite heavily for a decade, even I found parts of this book refreshing. I highly recommend it, both to beginning programmers, and crusty veterans like us.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Even with the "long long", C++ is still 50% faster than Java/Hotspot (and uses one third the amount of in-process memory):
./prime
$ cat prime.cpp
#include <stdio.h>
inline int isPrime(long long i){
for (long long test = 2; test < i; test++)
if (i%test == 0)
return 0;
return 1;
}
main(){
long long n_loops = 50000;
long long n_primes = 0;
for (long long i = 0; i < n_loops; i++)
if (isPrime(i))
n_primes++;
printf("%lld primes found\n", n_primes);
}
$ gcc -O3 -o prime prime.cpp
$ time
5135 primes found
real 0m41.019s
user 0m40.888s
sys m0.080s
Using JDK 1.3 (JIT) on the same machine:
$ time java prime
5135 primes found
Time taken = 59886
real 1m0.497s
user 0m0.030s
sys m0.050s
$ time java -server prime
5135 primes found
Time taken = 60387
real 1m1.228s
user 0m0.050s
sys m0.050s
I admit that the Java prime benchmark is quite lame, but results like this for Java vs. C++ is pretty typical.
"when it's compiled"
And I suppose the compiler doesn't need any resources to run? So who's the dumbass? BTW, post with your logon if you want to namecall.
political_news.c: warning: comparison is always true due to limited range of data type
Python (and eLisp too, for that matter) both have bytecode compilers. Don't know nothin' 'bout perl.
I tend to sympathize with the write-once-run-anywhere (WORA) advocates.
I haven't seen single cross-platform programming language that didn't have some platform-specific idiosyncrasies. You either have to avoid those areas completely, or try to code around them.
If you need those features, then you have to fix things for the specific platform at either compile-time or run-time. Compile-time means some kind of hack like the C pre-processor. Run-time means dynamically loading the correct version of some class. Either way, I say: "Ugh." That's not to say that either approach won't work, but it isn't as pleasant.
It keeps things simplier and saner when you're just targeting the same VM and standard libraries. You still have to have a bunch of conformance tests to make sure the particular JVM is compliant, but that's easier to maintain than platform-specific code in every application you write.
I've been doing mostly Java programming for the last couple months, and while there are a number of features in the language that annoy me, the overall development process is more pleasant than in other environments.
Though I did write this, I didn't post it here, and would not have. I wrote this to figure out for myself why Java seemed suspicious. Posting it on a forum like slashdot amounts to a troll.
I think this sort of article is barely worth writing (if something does suck, time will take care of it), and that's why on the site I put it near the bottom.
Seems to me that native Java would be virtually indistinguishable from native C++.
I can't believe how much Java has backed away from its cross-platform emphasis. Oh ok, let's make Jini for when you want to use Jave but need it in this special platform. And why not let you comile to a native binary? Sheesh... not much Java left.
You can do the same thing with C or C++. Or ANY language that you can compile. If Java compiled separately for each different platform is 'cross-platform' then so is C++. This DOES eliminate cross-platform as a benefit. And confirms the point that if you have a large, slow Java application where the speed is a serious problem, you should have written it in C++ in the first place.
I admit that the Java prime benchmark is quite lame, but results like this for Java vs. C++ is pretty typical.
Wouldn't the perceived slowness here be due to the JVM startup time, which really shows in this kind of "benchmarks". People using Java for run-once-quick apps deserve what they get anyway :)
.SIGSEGV
I disagree with your conclusion, but I find your comments most insightful. Particularly because you admit to be judging Java by its cover, and the reality is that the worst part of Java, IMHO, is its cover. It has little to do with the language strengths, and promotes a lot of its weaknesses (applets, anyone?).
... Likewise, the reason we hear about Java all the time is not because it has something to say about programming languages. We hear about Java as part of a plan by Sun to undermine Microsoft.
... Historically, languages designed for large organizations (PL/I, Ada) have lost, while hacker languages (C, Perl) have won. The reason: today's teenage hacker is tomorrow's CTO.
Let me try to address each argument. Note that these rebuttals are based on my limited experience and the impression I get from the language, and I'm no expert:
1. It has been so energetically hyped. Real standards don't have to be promoted... . On the hacker radar screen, Perl is as big as Java, or bigger, just on the strength of its own merits.
Java is not a "hacker"'s programming language, it's a software designer's programming language. A lot of what makes Perl so cool to code with is considered the very nature of evil by the people who liked (designed?) Java, so the techie radar screens tend to be pretty much apart.
However, Java has been hyped before it was ready to be hyped, and for the wrong reasons. Sun's vision of browsers running applets everywhere and for everything never made it, in part because Microsoft destroyed the dream of a standard JVM for applets, but mostly because Java's GUI libraries and the ISP's bandwith were not ready for primetime.
You will notice, however, that Java sneaked into the server market before anyone noticed, and has become the standard there. Suddenly Java was all about server-side applications, and servlets have replaced the old Sun vision after (and because) Java was already a success in that field.
2. It's aimed low. In the original Java white paper, Gosling explicitly says Java was designed not to be too difficult for programmers used to C. It was designed to be another C++: C plus a few ideas taken from more advanced languages.
That was a sintax constraint. It has little to do with the design of the language. I think you could make Java easy for Pascal programmers with some trivial changes to the parser and 1-based indexes.
Java has definitely different aims, and philosophies, than C++, and it doesn't aim low: binary cross-platform compatibility, transparent networking and serialization, fully object-oriented, language-level security and threading, good exception handling, etc.
Java was not meant to run in big hardware, it was meant to run in very small hardware in a network environment without compromising security. That's no C.
3. It has ulterior motives.
Most successful languages had nothing new to say about programming languages. They just partially implemented ideas from theoretically better programming languages, and owe their success to their sponsors' ulterior motives.
C is just an Algol-like language. So is Pascal (which you seem to think is "bad"; have you tried Delphi?), which was very successful. So is almost every language commonly used. C++ just patched up C with some objects and generics, no new concepts there. About the only real innovation Perl seems to have is the subtext of its design and semantics, not the language itself.
Lisp, however, owed it's failures to its innovative qualities, and it's successes to IBM and its ulterior motives. The only times I can come up with where innovation met with success is Smalltalk.
We are doomed to reap the fruits of innovation in the second generation.
4. No one loves it. C, Perl, Python, Smalltalk, and Lisp programmers love their languages. I've never heard anyone say that they loved Java.
You're probably talking to the wrong crowd. Talk to a programmer/software designer.
5. People are forced to use it. A lot of the people I know using Java are using it because they feel they have to.... These are smart people; if the technology was good, they'd have used it voluntarily.
People were forced to use C for decades. Then they were forced to use C++ for years.
Management rarely understand that such decisions should be left to techies, not to other management. When they don't understand the tools, they stick to (an arbitrary) one, and that's what everyone uses.
Smart people would use LISP/ML for a lot of things. Smart people would use Delphi for database applications. Smart people would use Smalltalk for desktop applications. Smart people would use C for OS development or device drivers only.
If you think C/C++ became the de facto standards they are because the technology is good, you are sorely mistaken. People learned C++ because they were forced to. People learned to develop GUIs in C because they had to. And people will always be forced to use a tool that is perfectly good for one thing, for something it's no good for.
6. It has too many cooks. The best programming languages have been developed by small groups. Java seems to be run by a committee. If it turns out to be a good language, it will be the first time in history that a committee has designed a good language.
I'm not sure, but I think the commitee was not there at the level of language design (unless you consider 5-people a commitee, in which case lots of languages, from Prolog to probably LISP, also were created by commitees).
Whatever the case may be, Java already IS. You can judge whether it's good or bad, no need to wait. Don't confuse the language with the standard libraries (which are part of the language distribution and the Java(TM) thingie, but don't define the language).
The commitee process in Java exists right now to standarize the libraries. For something like that you NEED a commitee.
7. It's bureaucratic. From what little I know about Java, there seem to be a lot of protocols for doing things. Really good languages aren't like that. They let you do what you want and get out of the way.
Java is not a hacking language. To "do what you want and get out of the way" is to do a hack, a quick one-time solution for a particular problem.
If that's what you need, great, but Java is not the tool for that. Some (perhaps most) programming problems require more thought on the security, stability and maintainability of the solution. Java, and many other languages, are tools for that.
Java is an object-oriented language, and by definition any OO language is bureaucratic. That's the whole point of object-orientedness: to provide extra layers of abstraction that will later allow flexibility. Messaging and more messaging. Smalltalk is bureaucratic too (it invented the bureaucracy), and yet almost all its coders consider it a great language.
8. It's pseudo-hip.
That, it is. But then again, if you don't take it seriously, Sun's PR is always entertaining.
9. It's designed for large organizations. Large organizations have different aims from hackers.
Java's libraries are designed for large organizations, but I think the language itself is not. Its only real constraint in that sense is that it is designed to exist in an insecure environment. The semantics are relatively simple and concise.
The reason Ada and PL/I failed was because they were semantic monsters, with conflicting features, and most of the semantics they had were not understood and used anyway. C++ is closer to that situation than Java.
10. The wrong people like it. The programmers I admire most are not, on the whole, captivated by Java. Who does like Java? Suits...
This all depends on who do you admire, and why. If they're kernel hackers they're not going to be captivated by Java: jet pilots are not captivated by 747s, farmers are not captivated by the concept of the supermarket.
Suits like Java. Now they like C#. Before, they liked C++, and at some point they liked an inferior OS system so much they put it everywhere and on everything (Windows? Yes, but Unix too, before). Suits like everything for about 5 seconds, good or bad, particularly if they read it can do something-ML, something-Net.
11. Its daddy is in a pinch.
Good point if it's true, but it would be hard for Sun to drag Java along with it at this point. The worst that could happen is that the standard stays at a stable 1.x version.
Or actually, the worst that could happen is that Sun is incredibly successful and manages to destroy Java by being careless with the standards, but I doubt that will happen.
12. The DoD likes it. The Defense Department is encouraging developers to use Java...
I think the DoD likes it because it's the only other language that offers security at the language level. It's either that, or creating their own language, or keeping Ada, which is pretty much the same thing.
Freedom is the freedom to say 2+2=4, everything else follows...
If your fridge asks the printer to print something, then status messages for that print job will be returned to the requester automatically. If the fridge has any message display mechanism, it can decide to display the messages. Or it can ignore them. What the fridge does with its messages isn't the printer's concern.
.Net to become more successful at this than Java due to MS's dominance of this type of client.
The printer and the fridge have no need to reprogram each other. They just need to send messages in standard formats appropriate for the class of device: a printer or a fridge.
Java was designed to run on general-purpose clients, and it's only there that the idea of sending executable code makes more sense than sending remote API calls. I think that will mostly mean clients with browsers, and I expect
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
The same place the Perl word processors, spreadsheets, databases, operating systems and real world applications are.
Java's good at different things. Java has been used to create really useful apps like Tomcat. It doesn't have to be good at the exact same tasks as C or C++ to be useful.
Everyone who talks about Java being slow is comparing it to C, I never hear people say Perl is too slow by comparing it to C. On server-side apps Java is much faster than Perl CGI's. Is this evidence that Perl is lame and useless? Or just that Perl is best suited for a different problem set?
It's the VB runtime, which is different from an interpreter. Learn the facts
Ummm.. ok.. lets look at what the VB runtime is. It is the native code for all the stuff found in an EXE created by VB. The EXE calls upon this DLL to do even the most basic funtions... (like evaluating an expression). This might be more like a virtual machine, but personally I think Virtual Machines are nothing more than beefed up interpreters.
If it ain't native code then it is intrepreted.
On a side note: I was simply pointing out that this practice exists. I wasn't totally faulting anyone for using it. Personally I think every tool has its place, and only the fanatical idiots will deny that. (Except the PC Jr. that was just a dumb idea altogether)
Actually, you've hit the nail on the head without realizing it. Java, like Perl, is a wonderful scripting langauge, and things like Perl are exactly the kinds of things it should be compared with. It's talk as if Java were in the same category as C or C++ that rankles everyone. If Sun wants to push Java as a much better alternative to Perl, I think people would be less rankled than when Sun acts like Java is the C++ killer or some such nonsense...
"Convictions are more dangerous enemies of truth than lies."
<sigh> Like it took me two minutes to type that... (silly slashcode...)
"Convictions are more dangerous enemies of truth than lies."
You put great store in hacking. Large scale development doesn't involve hacking. Leave that at home with ones other hobbies: writing reliable software involves discipline, whichever language one uses. As a C++ programmer, I found Java allowed me to very rapidly write reliable programmes with minimal fuss. It is very elegant compared with C++, and anything that helps lesser programmes produce code with fewer wierd bugs makes my job easier and costs the business less.
No, a 'long' in C++ is _at_least_ 32 bits. It may be more. Especially on 64-bit systems.
:-)
C++ doesn't have a 'long long' type. You're thinking of C99. Or a compiler-specific extension. (And, IMO, 'long long' is really fscking ugly. 'longlong' (one keyword) would have been better if it was _really_ needed, which it wasn't. Stupid decision by the C9X committee if you ask me....
Why doesn't the gene pool have a life guard?
runtimes and interpreters are not virtual machines. A virtual machine includes pseudo-registers, a stack pointer, etc. This is as opposed to runtime libraries, which are not interpreters, but binary code your app can be linked against, and which you can call the various functions.
Squishing an interpreter and its' script into an 'exectuable' is an old trick:
dBase executables, dbFast executables, vb executables, etc. Their idea of 'linking' is not the same as a true compiled language.
The idea of pcode was actually started a couple of decades ago with pascal pseudo-compilers, which compiled down to byte-code which could be interpreted by the run-time quicker. Now, of course, pascal compiles to object code (and you can do the same w. basic - remember Turbo Basic). The true test is if other languages can link against your object files.
Just a bit of history, for what it's Wirth (pun intended) (re Nicholas Wirth, so I don't get fl*med for spelling).
is still a language that's much easier/quicker to code in than C++,
and that has all the portability of the old Java, in addition to this (still vaporware) extra feature.
When in doubt, have a man come through a door with a gun in his hand.
Oh man ...
:-) and where not modded, ha ha.
:-(
:-) they are typical because no one very good in the C++/C area is realy good in the java area as well(or other way around). Most benchmarks are done by people who are biased to the one or the other ....
My last post some idiot moderated as flaimbate and the answers where mostly flames
Well, your post is good but you measure wrong
With the unix "time" command you mainly measure the start up time of the JAVA VM.
Embedd the measurement into your application.
Make for the C program a function and for the JAVA version a static method.
Then make a wrapper around it wich calls the function/method 100 times (or more often) and measures that time.
I admit that the Java prime benchmark is quite lame, but results like this for Java vs. C++ is pretty typical.
Yes
Also you have to bear in mind: low level machine instructions are easy to optimized for a specialized compiler. But a JVM vendor would not invest that efford as it butter and bread is the VM and the environment not the top performance on any version of x86 processor.
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
If you look at the Java data you can clearly see that startup time is only less than a second:
Damn, I need to start _reading_ the posts before replying :)
.SIGSEGV
64-bit add, subtract, and multiply work fine if the numbers fit in integers. Overflows on conversion back to integer cause an invalid-arithmetic-operand FPU exception, which Java can use but C has no idea what to do with. So that's fine.
Divide and mod are tougher to do as integer operations in the FPU, because fractional results appear in the FPU registers, but it's possible if the rounding modes are set to "round down". Note that the benchmark used "%", and it's possible that GCC doesn't try to do 64-bit "%" (which, after all, isn't used much) in the FPU.
Thank you all for the informed replies and the anecdotes. I have a better outlook on Java now and understand better where it is best suited.
:).
I think most of my 'questioning' Java has come from people who try to 'sell' Java as a panacea -- aka 'putting Java in light bulbs', "re-writing OS kernels in Java', etc.
What you mantioned is the clearest and best answer that I've hear for the reasons to use Java thus far -- aka you *can* do it in another language, but the support costs and development time for Java is a lot smaller. That makes sense and in that case the main costs to weigh when choosing Java over another language is what it will cost in developer/support time versus the performance losses.
Thank you for your answers, even though my question did get modded into oblivion