Following on from my previous article, the Java platform has an even greater image problem that is more than skin deep. Coming under yet another two-pronged attack, you’ll typically hear complaints falling into the two camps:
- Java is slow
- Java is a memory hog
The corollary being that Java on the desktop is infeasible for those without the patience of a saint. Funnily enough, in my experience, many people who have commented to me, “Andy, I don’t like Java because it’s slow” are the very same people who use Perl/Python/PHP. It suggests to me that not all the criticism is entirely objective! This article aims to discuss some of the criticisms aimed at Java and see whether they are justified.
Memory
To be honest, even the most faithful Java evangelist would have trouble believing that Java is light on memory usage (relatively speaking, of course). I don’t believe that it is, so I’m not going to pretend. Object-orientated languages typically have a slightly larger memory footprint as you have to carry around a lot of information about all your objects currently initialised. A large factor is simply the JVM itself. A simple “Hello world!” class of say a kilobyte will still require the entire JVM, and the several megabytes that entails. Yet, you must think about what you get for your money, so to speak. The JVM and the Java runtime classes are feature packed.
However, one man’s feature is another man’s bloat and I suppose this is where a lot of the debate stems from. When designing languages, you go either minimalist, and rely on the users to implement all the functionality they need; or you go for the opposite, and provide an extremely rich language where developers can rapidly produce software. As a Java developer, I don’t need to manage my memory programmatically: I can leave it all to the garbage collector. This is great for me, but not necessarily the most efficient way to manage memory. If you want to partake in old-school manual memory-management then you can do a certain amount (such as dereferencing your objects and then explicitly calling the garbage collector), but nothing as low-level as what C programmers would be accustomed to. There are other things you can do as a Java programmer to reduce the overhead such as using third-party libraries designed to be more efficient, such as fastutil or Javolution, which replace commonly used classes like the collections framework.
It’s worth being aware that the JVM by default doesn’t use all the available memory on a given system. This means that by default a Java application won’t overwhelm your system and cause heavy swapping and other such nastiness. Programs known to be memory intensive by nature, like scientific applications can in fact be limited by the JVMs conservative usage, and so many developers launch their Java apps with special JVM flags that permit Java to utilise additional memory.
Speed
To be fair, before I began looking into this, I had never thought that Java was the fastest language out there. I suppose, however, that because I’m still using Java, that I believe it’s fast enough. Assuming that C++ is the holy-grail in terms of performance because it’s so fast, then even if Java could achieve half it’s speed, it’s still fast! People seem to get so focussed on the milliseconds that they forget that if a task takes 0.01s in C++ and 0.02s in Java, then, “oh no”, it’s half as slow!
Yet, since mulling over this topic, I have found interestingly that Java has really made great gains in overall performance that can in fact put it on par with C++, if not a little quicker! There are various benchmarks that have reported Java algorithms running quicker than C++ equivalents. (Java Pulling Ahead, Java Faster than C++, FreeTTS case study) You will of course find many benchmarks finding the converse. What this shows is that they’re at least comparable which is enough for me to imply that Java is fast, and I’ll leave it to the benchmark zealots to fight over their nanoseconds.
I think Java is somehow still seen as an interpreted language; in fact, it does get compiled to native code using Just In Time (JIT) compilation. It is also a myth to think that JIT code is slower than pre-compiled code. The only difference is that bytecode gets JITed once its required (i.e., the first time a method is called – and the time is negligible) it then gets cached for subsequent calls. JIT code can benefit from all the same optimisations that pre-compiled can get, plus some more (from Lewis and Neumann, 2004):
- The compiler knows what processor it is running on, and can generate code specifically for that processor. It knows whether (for example) the processor is a PIII or P4, if SSE2 is present, and how big the caches are. A pre-compiler on the other hand has to target the least-common-denominator processor, at least in the case of commercial software.
- Because the compiler knows which classes are actually loaded and being called, it knows which methods can be de-virtualized and inlined. (Remarkably, modern Java compilers also know how to “uncompile” inlined calls in the case where an overriding method is loaded after the JIT compilation happens.)
- A dynamic compiler may also get the branch prediction hints right more often than a static compiler.
Even if it were slower, once again, you have to think what value for money you get per-clock cycle with Java. Many of the core classes are thread-safe as standard, for example; and let’s not forget free garbage collection. Also, that bit of code will run fine on all supported platforms without any additional effort. All the OS abstraction is done for you. That’s pretty incredible when you think about what it takes to actually pull off such a large abstraction layer like that.
Java Virtual Machine
The JVM once again causes controversy when evaluating Java’s speed. Java benchmarks typically discount the startup time of the JVM itself. Non-Java benchmarkers would consider this unfair, and not fully representative of the overall program performance. It’s a difficult debate. If I want to simply compare, say, raw Java Vector performance versus raw C++ STL vector performance, then why should we consider start-up times? Also, if I’m trying to profile algorithms within my program, again, why should start-up be useful in evaluating? But, if I’m comparing two programs that perform an equivalent task, I’d probably want to consider the overall time from initial execution to completion. Having said that, the larger the application, the less of an issue the JVM load times will be due to economies of scale. (Note, even this is getting better thanks to Class Data Sharing, amongst other things) One other thing to remember is that many Java applications are actually deployed as a Jar file (a glorified Zip file, essentially). You can execute the code within from the JVM directly – it therefore has to decompress the file first, and this obviously incurs a time penalty.
The Project Barcelona research group at Sun are coming up with some interesting technologies to improve the JVM in the future. That’s not to say that the current JVM hasn’t been improving steadily during each release. The Multi-tasking Virtual Machine (MVM) looks most promising as it’ll allow multiple Java applications to share the VM, reducing the overall burden on system resources. Ok, I know you can do this already on the current JVM, but it’s still a little raw. The MVM will be much more scalable and efficient. It seems to me that with such a system, you can finally run the JVM as a daemon on your system at startup, and then all subsequent Java programs you load will load as quickly as native apps. One can’t help but lose some optimism when you learn that the MVM may not even make it into Java 1.7 (Dolphin) due in the second half of 2007. I hope it does! In the meantime, you could to better than to look at some of the existing shared VMs like Janos, JKernel and Alta.
Java desktop
It’s on the desktop where many people form their opinions of Java, and it is here where people complain most about performance issues. The Swing toolkit is very powerful and rich, yet it is huge. Werner Randelshofer states that a Swing “Hello world!” program will require approximately 800 classes to be initialised before the user sees the infamous greeting. Yet, there is no shortage of Java developers who will tell you that Swing is fast.
Perceived performance
What those in the know will tell you is that Java in fact has a problem in perceived performance. You often hear about grey rectangles, unresponsive widgets, etc. The issue here is that Swing is perfectly responsive, until you hit a widget that triggers a task. The biggest trap Swing programmers fall into is that they don’t understand the threading model that is employed.
Here’s the science…
The Java designers decided not to make Swing components thread-safe, and instead opted for a single thread (known as the event-dispatch thread), to maintain the state of the GUI components. Therefore, your code that you want to run when a user clicks on a given button by default gets added to the EDT. If the code is something non-trivial, like loading a large file or querying a database, then this will block the EDT until it completes, resulting in an unresponsive GUI in the meantime. The remedy is to dispatch long tasks (i.e., anything likely to take > 0.25s) on their own thread, which frees up the EDT for doing purely GUI related tasks (see Ben Galbraith’s excellent tutorial).
The EDT approach is hardly exclusive to Java because it makes toolkit design much easier. You’ll find .Net’s Winforms opts for a similar model. The EDT is supposed to simplify things, yet it seems to be a common pitfall. Some one commented recently:
“… I may point out that Swing is not slow… The problem is that’s very easy to shoot yourself in the foot with Swing, but can happen with any toolkit, even those using native code. Well written Swing code can be as fast as a native application, if not faster.”
Shooting yourself in the foot
I was interested in this comment and decided to go off at a bit of a tangent here to examine if Java is really that prone to making unresponsive interfaces. I was discussing this with Jasper Potts from Xerto (producer of the visually impressive Java app, Imagery) and we got on to documentation:
“Swing itself is not slow, but that’s not to say that it’s that easy to write large applications that perform well. There is definitely room for some more articles on using Swing in the desktop… There is a real need for Swing books that tell you how to do things in the real world. [Desktop Java Live] is the first book I have come across that is trying to do that. Even all the books called “Advanced …”,”Extreme…”, etc., all they do is redo the Java [API] docs for the more advanced components. There are a few topics that just don’t seem to be documented at all well anywhere like the Focus System.”
Scott Delap, author of Desktop Java Live indulged me an a discussion on this topic too:
“Java/Swing being slow is one of those myths that has become embedded in the mindset of developers. I can easily write a desktop application in any language that is slow. I would suspect that 8 out of 10 developers that comment “Swing is slow” haven’t written a Swing app in at least 5 years. It is much like the Linux developer community labelling Microsoft as evil. Even if Microsoft became the best open source citizen tomorrow, it would take many years before the majority of developers would have this opinion of them. As far as countering the statement, I think the best rebuttal is the continuing production of quality desktop applications written in Java. The more there are the harder it is to argue against them.”
DJL devotes an entire chapter to threading in Swing. I asked Scott whether he thought threading was a common pitfall for Java Swing developers and therefore was it something inherently wrong with Java’s design:
“Anyone that is a software developer gets paid for a reason. Software development isn’t something that you can master in a three day correspondence course. I’ve always felt that it is each developer’s responsibility to become competent with the features of the language/toolkit they are developing with. Threading is a core part of writing desktop applications. You can easily find discussions about desktop threading on the Internet in regards to numerous other toolkits. It makes no sense to me when people complain about threading in respect to a language. No one complains they have to learn OO to use Java or for-loops to use .NET effectively. In regards to Swing specifically, it is designed very similarly to other common UI toolkits. If you look at QT, GTK, SWT, .NET, etc., you will see they all use some variation on the single event thread concept. Some have the concept of a global lock, however I’d much rather have the ability to address such complexities myself than a brute force approach supplied for me. I will concede that a few more threading utilities built into the core of Swing might help new developers. However, open source projects such as Foxtrot, Spin, and SwingWorker address a large portion of Swing threading related issues. Relating back to my earlier point, I think it is the responsibility of good developers to become aware of the tools that can enhance their development process.”
An interesting point here is that other UI toolkits use this threading model, but you rarely hear that these toolkits are slow. Yet, I have seen examples for most which also block the thread and therefore become unresponsive. I think Java has had some bad luck in that its legacy has stuck. Nowadays though, I do believe that if you see a slow Java application, the fault lies at the developer’s door, and not Java. For example, Eclipse had recently come under fire for becoming slow – especially with its start up. Critics automatically assume that this is because of Java. In its most recent M7 milestone release they significantly improved performance – a bottleneck being the plugin framework that Eclipse relies not being very scalable for increased numbers of plugins. The point being that this is an algorithmic issue – one that could have occurred in any language, yet it seems to become a Java issue. Of course, some more prominent articles and examples covering common pitfalls would certainly help to ensure new UI programmers get good performance from the outset.
Java2D
Some other performance issues have been down to the underlying graphics framework, Java2D. Because Swing components are all emulated, they are very much at the mercy of Java2D. Fortunately, this package is extremely competent in features, and by virtue of being graphics orientated, very quick too (i.e., performance of any graphics framework is a core priority, and Java2D is no different). However, the Java2D have been working hard recently to improve several aspects that should enhance this even further. One area is the use of hardware acceleration where possible. This must be a nightmare to implement in a multi-platform fashion, but it’s being done, slowly but surely. I hate to say it, but Microsoft has made this easier for the Windows platform due to its DirectX graphics abstraction layer. Windows users can expect to see this pipeline utilised even more in future releases. The OpenGL pipeline is also being advanced significantly which will benefit all platforms (currently, support is disabled by default but can be switched on; this will be enabled in the next release.)
There are also a few little tweaks for Mustang that will even help in the “perceived” performance problems. For example, the abolition of the infamous “grey rect” problem. The fix required the use of true double-buffering support for Swing, which is another great boost for the toolkit.
Will someone please think of the users?!
As a Java developer, I will happily sacrifice some memory, and a bit of speed, because the Java platform affords many other benefits. I find myself being productive with Java because of its richness and ease of use. I do benefit from the multi-platform aspect too, because I use Linux to develop yet many of my typical users are on Windows.
However, the argument is that a potential end-user doesn’t care how you made the software, but simply how well it works. If my program becomes unusable due to say, lack of memory, that’s one disappointed user. Are they happy that you’ve sacrificed resources to make your life easier? Well, I’d like to think that such cases are extreme and that actually users will be happier that one uses Java, because I can produce better software with it. I suppose that if I knew in advance that the target machine specification was one where CPU and memory resources were at a premium, then I expect I would consider strongly the alternative technologies. But, much can be done to make your Java code more CPU and memory efficient, but you have to program specifically for that.
Summary
My experience with Java Swing (as a user and a developer) over the past year has been very positive. There was a lot of mud slung at Java in its early days and I reckon that much has stuck. This is in spite of Swing – and Java itself – being faster than ever. There’s no reason that Java applications should be poor performers nowadays… unless you’re low of memory, that is. Memory consumption is still a make-or-break issue, I think. The “memory is cheap” come-back is not very useful in this situation either, and I think Sun knows this and are hoping to continually improve on this issue. Yet, don’t be fooled into thinking that it’s only Java that can suffer from memory issues.
Despite all that’s been discussed, I know that this will not help to change many peoples’ minds. As Lewis and Neumann say “…in web flame wars, people are happy to discuss their speed impressions for many pages without ever referring to actual data.” I’d like to think that those Java critics reading would re-examine the current state of Java, especially with the many enhancements coming in the next release. Joshua Marinacci recently blogged: “When I see an ugly webpage I don’t blame my browser, I blame the site designer.” This can now be applied to Java performance issues, insofar as poorly performing Java programs are due to poorly programmed Java code, and not because it’s a Java program.
Probably the only real way of proving how far Java has come is by demonstation, yet Jasper pointed out:
“Java lacks the great applications that show what is possible; some are getting there like Netbeans or IntelliJ but nothing mass market. Limewire is ok, but you can’t say wow! about it.”
Perhaps this is why the perception of poor performance still exists: think of all the typical everyday apps one uses, such as email client, browser, IM client, media player, etc. There aren’t many Java examples within those categories. I bet within the enterprise, there are lots of bespoke solutions that already show off Swing’s potential – yet we’ll never see them. Many Java developers are aware of Java’s capabilities because many of the best examples are tools for Java developers! I’ve found apps like Intellij – a massive and complex Java IDE – to be blisteringly fast. Java is already good enough for the desktop, but I really believe that Mustang will be a watershed release and we’ll be seeing quick growth of (well written and good performing) Java desktop apps in the next couple of years.
I’d like to thanks Scott Delap, Jasper Potts and Romain Guy for their input and suggestions to this article.
About the author:
Andrew Roberts is a computer science graduate from the University of Leeds, UK. He remained at Leeds to study further towards a PhD in Natural Language Processing. He has been using Linux for almost 8 years, and Java has been his language of choice for advanced language processing and machine learning during the last three years.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
especially j2ee apps. the problem is, no one ever uses the right language for the job anymore. they just always use java. and i’m *so* sick of hearing people say java is just as fast as c++. its not true, i don’t care what benchmark you show me, it just not true.
there are two really easy test to prove this.
1. write a program to parse a large xml file in java, and then one in c using libxml. the one in c (or c++ for that matter) will crush the java one (i know, i’ve done it). this is even bigger issue because java people (i am one, sigh) use xml for *everything*. the same way they use java for *everything*.
2. Create a simple object that just has one member, a string. do this in c++ and in java. now write two mains, that just create 1000 of these objects. Time it.
Sorting ints, or accessing a hash may be just as fast, but the applications people write are not.
Right now bea workship is taking 100M of ram (and it has the least features of any java ide that i’ve used). If i start the weblogic server, i’m up to about 300megs…
Speaking only for my personal experience most of the Java Apps I have used sucked. You can rant till you are blue in the face but untill I see good fast quality java applications I am going to still have the same opinion.
How do you think so many people independently formed the same opinion of Java in the first place?
Also, didn’t Sun buy an Apple app like Watson with the intent of re-writing in Java and releasing as freeware to show the world just ho easy and fast Java can be?
What ever happened to that project? This was not easy or fast even for Sun Microsystems?
run on many platforms straight away without modification ?
> run on many platforms straight away without modification ?
this is true. and this is a case where java is the right language for the right job. my beef is with all the j2ee development going on where the people coding control the hardware they deploy to.
Being able to write once, run anywhere is great, but it has a cost…speed and memory usage.
In 1) are you using DOM(Object Model) or SAX(Event Model) for parsing XML?
If it’s DOM then both (1) and (2) are stressing the same issue with Java which is Object creation. Object creation performance has always been one of the things holding Java back, Sun have made large leaps in improving it but there is still a way to go before it could get to C++ speed and it will never quite reach it as Java has extra overhead to keep track of object for later garbage collection. I think this is an area Sun should look at in future JVMs
If it’s SAX I am suppressed, if you are purely looking at parsing performance and not the complete time from application start-up then I think the performance will be very similar with C++ and Java.
Another aspect which tends to make Java apps ugly is widget layout. Java along with a few other GUI kits use the concept of layout managers (note that Windows developers don’t use layout managers), unfortunately if one isn’t very careful with these (for example, the programmer is lazy) then it is all too easy to create ugly layouts. How often has we seen a row of edit boxes right up against a window margin and positioned one beneath the other with out any spacing? Couple that with poor look and feel, ugly fonts and with a little bit of performance drag (yes even today on GUI apps) and bingo, Java gets a bad name.
> Java is dead. Long live .Net!
I hate MS just as much as the average osnews reader. I don’t use windows at home, only at work.
But, I have had to write some .NET code (in C#). Here’s the thing, and it pains me so much to say this…C# is a more powerful language than Java. Now, I’m talking C# vs. Java, not .Net vs. the Java Foundation classes. I think the .NET framework is a hack compared to the java class libraries which actually seem thought out, as .NET is just another wrapper around win32. I think they rushed .NET and it shows in the API.
Yes, libxml is dom, and the java was dom too. I haven’t tried it using a sax parser, but since we’re talking about object oriented code here, and we both agree object creation is slow…
Good point though.
“SAN FRANCISCO–As part of its push to boost Java on personal computers, Sun Microsystems has licensed software called Watson that’s used to find and present information from the Internet.”
Article from 6/30/04 can be found here:
http://news.com.com/Sun+licenses+search+software+for+desktop+push/2…
In general, the user experience exhibited by most of the Java applications I have used, both on the desktop and via Web browsers, can be characterized as frustrating, irritating, sluggish and just annoying. I do not understand how anybody can claim with a straight fast that Java applications, at least the desktop/GUI ones, are fast. In my narrow experience, they aren’t and have never been. Heck, to add insult to injury, I run several GUI applications written with Python that run faster than any GUI Java app I have ever used.
Also, I don’t care if Java developers suck. I don’t care if nobody knows how to code Java GUIs. All I know is that it will take pounds valuable gems for me to consider contemplating installing a Java application, talk little of actually using one.
The only exception is if the user experience is compelling enough, or if the functionality the said Java app provides is unparalleled. SUN has a lot of work to do. Why won’t Java advocates admit this so that SUN can at least fix this issue?
1. Java is a compiler and people don’t understand that . It takes time to compile code.
2. Java memory usage can kill older PC’s. I had a 32 meg pc and the virtual memory/pages usage was ‘terrible’ .
3. Java startup time used to be slow. Now it’s ok.
Java even has an OS out now.
http://jnode.sourceforge.net/portal/
Java maybe should copy Euphoria language. A fast interpereter with a C compiler. Pretty cool even if they copy C a little too much.
I use these Java applications everyday. The first two I find very responsive and are my favourite in their class on Windows. The last one has some responsiveness problems, but I still find it very useful.
FreeMind
jajuk
Ganttproject
Another Java application that I use occasionaly that I find very responsive ans useful is jalbum.
Based on my experience with these applications, I find there to be no significant speed problems with Java, for me.
Sometimes I feel that people misunderstand Java. Personally I like C++ better, but Java has a big advance definitelly. Beyond the language it provides a proper infrastructure (network, thread management, GUI etc.).
Just let’s assume that you’re a developer and you would like to create a general application with UI, networking etc. in C or C++. Probably it should be portable also. At this point you start to find proper libraries for these things. In C and C++ world this is a big headache, but not in Java world.
So don’t complain. Java provides safe and portable way of the application development but it has a price of course…
I have not much idea about Java internals, and I don’t code in Java.
Speaking as a user only, there are nice application written in Java, but their interface and loading times feel incredibly sluggish.
As a previous poster said, the author can rant all day long, because this slowness is all I have to judge.
What about those of us who want to use it, but can’t because of licensing issues. I think most of us understand the benifits of Java and we would love to be able to use it, but Sun just doesn’t seem to understand the problems we see with the license.
With how bipolar Sun can seem to be at some points it’s no wonder we want a more open license, what if tommorow they decided, we want to do the most damage we can to every app out there that uses Java. This may not seem like a smart idea on Sun’s part, but that’s not the point. If they did do this, could they cause problems? Would different licensing help to resolve this? What if Sun got bought out by another company that could benifit from causing problems for Java in general?
I think a lot of us are much more concerned with these issues than the techinical aspects of Java.
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
How can that be true ?
>Another aspect which tends to make Java apps ugly is widget layout
I do not agree. It’s easy to make poor looking applications in ANY language. Although the GridBagLayout in Java may be hard work for new commers to Java once you have a firm grasp of it you can make some very nice looking apps.
The alternative is to us a GUI layout tool such as the one that comes with IntelliJ.
Azureus is the only Java application I’ve knowingly used that
doesn’t make me want to vommit. And it still seems somewhat sluggish. But it’s got lots of features, looks relatively nice, etc.
Mostly I’ve only used Java as a web-app and usually they only work on MS/IE and generally suck or don’t behave correctly with the wrong JVM or any number of other issues.
I tried out OpenNMS once… it’s reliance on Tomcat and Java made it unusable on the system I tried it on. It started swapping almost immediately and never quit.
My opinion of Java will improve when the Java apps I use don’t make me want to die…
> http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
> How can that be true?
Because its straight math, no real IO, threading, object creation, etc. The JIT compiler can compile that to pretty good machine code. It just sucks at doing everyhing else.
“run on many platforms straight away without modification ?”
I can run my C/C++ apps on more platforms than my Java apps. Who cares it it needs a recompilation if Java is not supported at all. Take the Sun JVM–it only runs on Windows, Solaris and Linux. You know that virtually every platform has at least a C compiler available. Java is very limited in this regard.
Commenting on the article…
Its the GC and the omnipresent JVM that are responsible for the huge memory demands of Java. C++ or Ada are OO as well and don’t need that much memory. And guess what the alternative to GC is not C style free() — its destructors (the real ones) in C++ or controlled types in Ada. Java is also slow compared to C, C++ and Ada. And where it isn’t it needs much more memory to achive speed.
It’s not. The only way Java outperforms C++ is if virtual methods are overused in the C++ code, as the JVM can inline virtual methods on the fly. Furthermore the tests do not take into account the overhead of the JVM itself.
Here were some benchmarks I did on Java vs. C from awhile ago:
http://fails.org/benchmark.html
>Object creation performance has always been one of the things holding Java back
Object creation is expensive, but actually Java beat c++ here… Manual memory optimization for c++ could lead to better performance, but in real life gc makes pretty well.
…is the fastest Java IDE out there and uses Swing. Netbeans on the other hand, also uses Swing and continues to be, despite large improvements, relatively slow. Clearly Swing/Java is NOT the problem here.
If built in garbage collection and a virtual machine made application front-ends slow then VB would be slow.
Here’s a real test for java, write the same gui-heavy app in Java and VB compare the performance of the interfaces. Or, if a single person isn’t qualified to do both get two people qualified to create the apps.
if java isn’t made to be fast but to run everywhere, WHY ISN’T THERE A SUN JAVA RE 1.5 FOR Linux/PPC ? they have 1.3 for linux/ppc and there’s an IBM jre 1.4.2 but this is old. even .Net runs on linux/ppc using mono.
Object creation, as noted is costly for Java. Reusing objects to avoid the initialisation cost will help dramatically. There are many articles (see Google!) One that caught my eye was this one:
http://www-106.ibm.com/developerworks/ibm/library/it-kelby_tips/
But like any language it has its niche’s and it shouldn’t be brought outside of them until its problems can be hidden by rediculously powerful machines and tasks with constant complexity (non-increasing at least).
Java can be great on the desktop, if you use a lot of Java programs. If one can assume you will use many java program then loading the jvm can be a part of system startup (much like how the common c libraries are going to be loaded while booting most any OS).
In a sense, you now have ALL your libraries sitting in RAM. Where with c++ you have 150 different libraries where some of them may only be used by a program, and they’ll have to be loaded when that program runs the first time! This is a small task if you have a computer that was made in this millenia; but loading a JVM is still a noticeable task (about 10-20 seconds now?),
But the next thing to keep in mind is the garbage collector. They’re great for quick application development and letting you have less strict memory practices. However, if your program would leak more than a few percent of the system RAM a second without the collector… Well, that collector is going to be using a LOT of cpu time. Where does this happen anyway though right? Well, we all know that Java is not the language of choice for video editors!
If you’re still on a PII like me, you probably don’t much care for using a Java program. But, if you’ve moved into this century, and bought a proper amount of RAM; then you shouldn’t mind the extra 30MB of RAM used and the cpu time taken…
That said, Java keeps it’s old lore from back when PC’s weren’t quick enough to make Java snappy…
.Net runs on PPC by virtue of Mono. Therefore, it’s not Microsoft’s efforts that are helping you here. Likewise, you can use a Free Java implementation, rather than Sun’s, to get your Java app running.
Kaffe lead dev, Dalibor Topic, told me that Kaffe (a Free VM) has been ported to ~70 different platforms.
So, just like you use 3rd party apps to get .Net to run on unsupported platforms, the can be applied for Java.
Isn’t this a matter of personal preference? What is too slow for you may not be too slow for someone else, and vice versa. So if I say it is too slow for me personally who are you to argue? If you think it runs just fine for your needs, than who am I to argue?
The fact remains that some people think it’s too slow, and this is not really up for debate. You can try to make excuses if you want as to why Java is as slow as it is, and you can even try to convince people to still run Java apps even though that person thinks it is slow, but to sit and argue that “it’s not slow” is kind of pointless isn’t it? You can think what you want to about Java’s speed, but I think it’s slow – case closed, end of discussion. It runs slower than any other native app I use.
Hell, it probably runs the same speed on both of our computers, just that I am a bit less patient than you. As I said, it’s just a matter of personal preference.
Swing still looks like crap…but, there is a build coming out this week of Mustang (B39) that will address the font problems (subpixel rendering).
Swing really isn’t slow anymore. Both Netbeans and IDEA are pretty zippy on modern machines, but Sun had been pretty content to have Java live in server-space (which its been a success) and not concentrate on the desktop.
I’ve only used Java for half of its life, and I’ve never seen it take 10-20s for a JRE to load up. It’s not like I’ve had really fast PCs either.
I’ve used Moneydance (http://www.moneydance.com) for personal finance for a while, now, and it is 100% Java. It runs fine on Solaris, even though the Moneydance folks don’t list it as a supported platform. It’s performance is fine, too, even with big check registers open. While Moneydance isn’t as feature complete as Quicken, it beats the pants off of GNUCash (Moneydance: unpack and run; GNUCash: uncompilable and unportable and quirky).
Using apps like these remind me why Java is a good thing. Java portability is real, and even the little things Java programmers sometimes have to do for portability pale in comparison to C and C++. C and C++ portability is hell, especially when I see programs dictating a specific point release of g++ or C programs with pages of #ifdef blocks.
I completely agree with you, as performance is subjective. The point is, I’ve heard directly from people who haven’t tried Java for years (as a user) and yet are still convinced that Java is slow. How people can make their mind up with out actually trying it out (considering how quickly technology progresses) is beyond me, and was one of the reasons why I was appealing to readers to scrub what they “think” they know and find out properly. Things have improved a lot.
Naturally, some people still want their buttons to click quicker than Java’s buttons, and there may never be a time when those users will be satisfied.
I was thinking the same thing. Generally I don’t mind Java apps. I also realise that Java or the JRE is just going to get better and better.
So taking all that into account and knowing that I change OS’s and computers regularly I really like the idea of using all Java apps so I can change OS without having to worry about how I am going to get all the data in. Just need a good Java PIM or email app and I am set.
>> http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
>> How can that be true?
>
>Because its straight math, no real IO, threading, object >creation, etc. The JIT compiler can compile that to pretty >good machine code. It just sucks at doing everyhing else.
To make matters worse, as usual, odd-ball logic from these Java guys even come to the wrong conclussion. No real surprise. The crowd that those benchmarks apply to tend to run simulations which can run for days or even weeks. Their conclussion? A 20% performance impact is close enough. Puke. At a day, that’s 24-hours versus 28.8 hours. At a week, that’s 168 hours versus 201 hours; that’s an extra day and half!
Anyone that wants to pretend Java is anywhere near as fast as C or C++ can do so, just stop lying to me about it.
Simple fact is, every benchmark I’ve seen that compares java to C++ either has really crappy C++ code and very well optimized Java code and/or finds optimial corner cases which do not reflect real world conditions and build a benchmark around it. Worse, almost every benchmark you’ll find purposely avoids collection, which completely hides GC-overhead and the associated overhead associated with memory management, that all programs must pay. Once again, a dirty lie.
These are THE primary reasons why Java has not respect. The developers constantly lie, cheat, and steal in attempts to gain mindshare. Stop it. No one is buying.
Sure Java is often fast enough. Leave it at that. Java is not a good general purpose tool and that’s the real problem. There are much, much, better general purpose tools available that come with far less bagage. This is the problem Java has.
For the last 2 or 3 years, I’ve been firmly planted in the C/C++/native code/QT/GTK camp for desktop applications. I’ve even been in that camp for enterprise development.
However, all along, I always saw many of Java’s virtues like J2EE, automatic memory management, easy cross platform support, developer productivity, massive killer APIs, etc.
At the same time, as an IT professional / programmer (how I earm my living and support my family), I’ve seen how C/C++ development jobs have been becoming increasingly scarce, while Java/J2EE jobs have been becoming increasingly abundant. In fact, Java/J2EE is nearly ubiquitous for all development jobs (except for Windows specific ones, which often go with .Net). And the C/C++ job postings are quite often actually Java/J2EE jobs, where the legacy C/C++ code is being converted to Java. Just do searches on Dice.com, Monster, Hotjobs, or craigslist, and you’ll see the multitude of Java job postings greatly outnumbering the C/C++ ones.
So with my desire to have continued success in my IT/programming career (and make more money
), I therefore have a natural attraction to Java. Sure, I would love to be paid hamsomely to write QT/C++ or GTK+/C code (I love both of those environments for desktop apps), but the amount of job postings for those is zero. So I’ve been learning/brushing up on Java the last few years.
In this process I’ve been discovering some things about Java, shattering some of my preconceived notions:
a) It’s not slow FreeMind, as mentioned by another poster, runs great. JBuilder X Foundation runs great on my 300MHz, 228 meg memory machine.
b) It’s not as terrible of a memory hog as everyone makes it out to be – above apps did not cause swapping
c) Java apps can look great – JBuilderX looks terrific
d) Java app load times are usually acceptable FreeMind loaded nearly instantly. JBuilder takes a while to load on the 300MHz, 228meg machine, but once loaded it’s quite zippy
e) Many C++ apps are slow, or use lot’s of memory, or have slow load times – OO.org, a C++ app takes forever to load, and uses tons of memory. Same with Mozilla/Firefox
f) Apps I write myself, using AWT, Swing, applets, or just command line, are plenty fast and don’t take long to load, even on the 300MHz, 228meg memory machine.
So, while I remain a fan of C or C++ compiled code, as well as GTK and QT, my negative stereotypes about Java speed and memory usage are vanishing. I suggest that other posters here give some Java apps a try.
A good place to start is: http://www.java.com/en/
What benefit is there to writing a desktop application in Java over C++?
I have experience in writing desktop apps for both languages, I’ll list the common pro-Java arguments along with what I’ve found:
Write once, run anywhere –
I can do this just fine with C++ and a multiplatform GUI toolkit (e.g. Qt, wxWidgets…) Sure, I have to compile for separate platforms; but I’m also not restricted to only run on platforms that Sun supports.
Java is better for rapid development than C++ –
If anything, I’ve found the opposite to be true. Java forces some conventions (everything’s a class) that turn the most simple application into a novel. If you want rapid development, go with Python and Qt.
Java has great support libraries –
Sun has included a lot of functionality in the JVM, no doubt about that. It is nice to have it packaged and ready to go. That being said, one would be hard-pressed to not find a C++ library that corresponds to every Java library.
Something that seems to be always forgotten when comparing java or .net to c++ is the speed of the compiler. I found that the java compiler is around factor 100 (yes you read correctly) faster than gcc. This makes it possible for IDEs like eclipse to compile as you type! These are features that make me more productive as a programmer, which is far more important than pure speed of the environment.
I have done my own tests and can say that java is pretty fast. I rewrote once small python app in java and java version was 5x faster. Sometimes java is even near as fast as C/C++ or even faster.
We have a server running totally on tomcat, it had been on a commercial j2ee server before.
With both the previous j2ee server and tomcat we have to cycle all of our java apps about once a day otherwise the performance heavily degrades.
A big problem with our server is that it does lots of heavy memory allocation and deallocation sometimes in very large chunks. We’re very seriously looking at reimplementing critical portions, if not all of the server in c++ in addition to some other redesigning.
The problem with java is that everything except primitives is a heap based object. A simple example:
PointF[] data=new PointF[1000000];
//Fill with some points
This array will consume 8 megabytes in languages with value types such as C++ or C#, but 24 megabytes in java. Every single point in the array has the overhead of a heap based object which is usually around 16 bytes on a 32bit architecture.
Probably even worse: in languages with value types iterating through this array will access the memory in a very ordered manner so that the CPU cache can prefetch everything. In java there are 1000000 objects on the heap, and while the memory allocator tries to allocate objects close to each other the java program will never have as good memory locality as the value type version.
There are ways to optimize this, but the java VM does not make any effort to do this. It does not even allocate locals that don’t escape the local scope on the stack even though that would be relatively easy.
The decisions sun made with the java 1.5 generics implementation even increase these problems.
> A large factor is simply the JVM itself. A simple “Hello world!” class of say a kilobyte will still require the entire JVM, and the several megabytes that entails. Yet, you must think about what you get for your money, so to speak. The JVM and the Java runtime classes are feature packed.
http://www.smalltalk.org/smalltalk/history.html
Smalltalk was invented in 1972; today’s Smalltalk is based on Smalltalk-80. In front of me, I have a book, called “A Taste of Smalltalk”, which has screenshots of a complete implementation of Smalltalk running on an IBM PC AT, as well as one of Apple’s implementations of Smalltalk running on a 512K Macintosh. These were all graphical systems (a fair amount of concepts we take for granted today were invented for the smalltalk ui).
Smalltalk is cross-platform – several implementations exist for all the common platforms, such as Squeak and Cincom VisualWorks. Squeak is less than 20 megs zipped, including both the VM and ‘image’ file; the full image comes with several games, a paint program, a music player and recorder, a movie player, support for 3d graphics, and a lot of other stuff. Smalltalk code is much more compact than Java code. When there’s a bug in a Smalltalk program, a dialog box pops up (this can be overriden by the programmer), which allows you to debug the code, evaluate arbitrary expressions, and then continue as if nothing had ever gone wrong – starting from an arbitrary point in the backtrace. With Java, you generally get a one-line error message and your program exits unrecoverably – you can work around this to a large degree, but it’s the default behaviour.
Smalltalk is a JIT compiled language (I believe the whole JIT conecept was invented for it). It has a virtual machine, and cross-platform graphics and sound libraries. It is garbage collected.
In raw performance, it’s not the fastest language out there, by any means – but every Smalltalk app I’ve used has felt much snappier than even trivial Java apps. Modern Smalltalk implementations are certainly lighter on memory usage than modern Java ones. I currently have to use Eclipse, which is much, much clunkier than VisualWorks; try both for a while and compare them.
There are many languages which provide serious advantages over C and C++; some of the functional ones even have comparable speed. Garbage collection is great, but one does not need to use Java to have it. Aside from the advantages of having a large community and recognition, Java has few advantages over some of these languages.
>I have done my own tests and can say that java is pretty
>fast. I rewrote once small python app in java and java
>version was 5x faster. Sometimes java is even near as fast as
> C/C++ or even faster.
That generally means the C++ code was very poorly written. Comparing Python and Java is generally unfair as Python is not generally compiled. Did you try comparing your Python implementation against a Py -> C exe? How did it do with Psyco (a basic JIT for Python)?
What was the nature of your application? Was it a utility (run briefly and exit?) or did it run for hours at a time, allowing and accounting for collection? Remember, Python generally collects after each object falls out of scope.
Don’t get too obsessed about benchmarks because it’s nearly impossible to do a fair test between two languages. When Java comes on top in a benchmark it’s because the C++ code was rubbish, and the same is often true when it’s the other way around. I’ve seen tests where they compare gcc with varous optimisations, Intel’s compiler, and then Sun’s JRE. Java often came ahead of gcc but practically always beaten by Intel C++. Yet, if they had also tried the faster IBM JRE, they would have been likely to see a very similar speed. But they didn’t, and so they concluded just on their observations.
I never believe the benchmarks. I never expected to see any that reported Java being faster than C++, but I did, and when you look in to it, you seen that JIT has some great advantages. The point is, with so many benchmarks, giving varying results mean that it’s probably much closer than you think. If you look at graphs, you’ll notice that the axes are scaled so that very small differences look massive.
One of the best recent articles about java performance
finally
** Warning// Personal preference and selfishly biased comment inside
Just to add my two cents.
While Java might be fast, I have yet to see the first java application that runs fast (I tried a lot of them so far, and not even one has become the tool I would continue to use) and does not consume all the memory after running for a while.
For now all I can see about Java applications is:
– they aren’t fast (at least I haven’t seen one yet)
– after running day or two memory consumptions go over the limit (scratch disk goes crazy)
– looks like sh**
– usability feel is completely another universe than underlaying system
So,… I can’t help my self but to say that I don’t see Java as viable solution (for me at least).
I agree. The java crowd needs to stop crowing benchmarks. The performance difference between C/C++ and Java is almost always huge in real world applications. I can remember reading a Java vs C++ benchmark not long ago where the Java benchmark was faster. Why? Because the benchmark purposely avoided collection, thusly hiding a huge performance effect. Solution, I obtained the author’s C++ code, slapped in a GC for C++. Results? C++ was 500% faster.
Time and time again, Java developer’s prove that they do not even understand how to benchmark. And frankly, comparing the two languages on an even balance is a tough nut. They need to stop the lies and misrepresentation and tought the strengths that Java REALLY does have. As soon as someone brings performance into the mix, and the phrase, “good enough”, isn’t used, a lie is almost certainly to follow. Please guys, stop the lies and simply be honest. Tell people what’s great about Java. Stating that Java is on par with languages like C and C++ is simply not true.
Actually, that’s not true. The 500% improvement was for removing his delete’s from the code, which mirrored the behavior of what Java was doing, as it never collected. Using the GC resulted in somthing like a 300% performance improvement and that was without tuning the GC at all.
The developer of Imagery was quoted in the article. I am really looking forward to trying that software to see if it is responsive.
It looks great!
Andrew
Does the app perform acceptably fast for the user? And if a server app, does it perform acceptably for each user under a given load? Does it scale “well” (app and environment dependent)?
That is the ONLY criteria.
Java GUI looks are utterly irrelevant as not five users on the planet care. Not to mention being utterly irrelevant vis-a-vis performance.
Quality of design is the only criteria of significance in determining performance, with code quality being second. Language choice is a distant third.
Finally, C++ is hardly a PLATFORM. It is a LANGUAGE. Sure, it probably has tons of freely available libraries, too, after many years (and more non-free ones since that sort of thing preceded OSS). But c++ is NOT a PLATFORM the same way Java is. How many OSS workflow managers do you see written in C++? Web application servers? Business rule engines?
When’s the last time you wrote an applet in C++?
When’s the last time you heard about connecting Web browsers to C++? Perl? Yeah. Java? Yeah. Python? Yeah. C++? Gimme a break.
The main reason people trash Java is because they’re Windows Visual Basic or Windows Visual C++ programmers. Take a hike!
Here were some benchmarks I did on Java vs. C from awhile ago:
>> http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
>> How can that be true?
>
>Because its straight math, no real IO, threading, object creation, etc.
But you see, that *can’t* be true. Because Java defines floating point math to be the same on every platform (IEEE754), which means you can’t use any floating-point hardware that has extensions to floating point math. So either they’re not using a conforming Java implementation, or their C++ code sucks. And the state of the art of Java in 2001 was a *lot* worse than it is today.
>but can you C++ app…………..
>run on many platforms straight away without modification ?
Yes. Try wxWidgets.
Also, have you tested your Java app on all your platforms? Different vendor’s JVM’s, etc. I doubt it.
I’m not a fan of Java on the desktop. Speaking as an end-user, I have used various desktop Java apps at different companies. These were all custom apps written in-house (I’m using one at my current workplace too). The one thing that distinguishes all these apps is their slow, sluggish performance. So no, I’m still not convinced that Java on the desktop is fast. No amount of arguing about about poor coding is going to change my opinion (or that of other users) – it’s the end result (or “user experience”) that matters, and Java simply fails in this respect.
As for cross-platform capability – who benefits? You as a developer? Or the end-user who has to put up with a sub-standard UI that conforms to the most basic common elements across different platforms so as to not break that all-important “cross-platform compatibility”? Give me a fast, natively compiled app, fully tweaked for the platform it runs on and able to take full advantage of all the features of that platform (regardless of whether any feature exists on another platform).
Finally, as to the perception that Java used to be slow, but is now much faster, well, I’m not convinced about that either. PC’s have certainly got faster, so it naturally follows that any software will also run a little faster including Java. Perhaps a better measure is whether the most current version of Java runs faster than previous versions on older machines.
It always seems to be developers claiming that Java is fast on the desktop. You rarely hear the same from end-users. In general, I try and steer clear of installing any Java apps on my PC at home, and that means I’ve disabled Java in my web browser too!
No real numbers to refute that Java is slow. The author admits that Java takes up more memory, takes more time to run and looks uglier. How anyone can come up with the conclusion that Java isn’t bad is beyond belief. Where’s progress when a newer programming language does worse than existing ones.
The reason why Java survives at all is because clueless project managers locked into it as the current buzzword. I don’t know how many conversation with managers I’ve been involved in that didn’t make any sense. “It is the company’s initiative to think outside the box and to synergize by ciscoing the java, and XMLing the voip”. You could have the best legacy app in existance and some dumbass will want to replace it with something inferior because the old app is no longer shiny and new. I never understood why cross-platform was so important for businesses. Most businesses run the exact same desktop hardware for all their workers. Same platform, same OS, same apps. Easier to administer if every PC is identical, easier to create in house apps. Cross-platform made sense for home users that do have a variety of hardware/OS/apps but home users have been choosing not to run Java.
I’m so frickin tired about how fast a java program starts. Guess what,launching any program via citrix(e.g. Word) is three time longer (at least) than starting a quite big java app. And guess what!Managers find this response time very good! So, I don’t want to hear anymore java app takes ages to start.This is very relative.
Very well written article. I have been using one program on Os X through all its versions. The current version on Tiger seems to quite slick. While it ‘appears’ to be a little on the slow side, it is perfectly usable. The application is called Sequence Analysis for those interested in molecular biology (you can find it on Version Tracker).
Flame War,
Flame War!
Party time,
Excellent!
Thanks for the great article, as well as your previous article, which was an interesting read!
Concerning performance: a while ago I wrote some a simple language analysis program in Java on NetBSD doing many balanced binary tree operations. JDK 1.1.8 was the last “blessed” JDK for NetBSD, and that is what I used for the initial developent. Lateron I switched to JDK 1.4.x for Linux on NetBSD. The run time (mostly consisting of tree operations) was ten times shorter with JDK 1.4.x than with 1.1.8. I wrote a program that did the same operations in Pascal and compiled it with FreePascal, except for the startup time the performance barely differed. After that I stopped worrying about Java vs <insert other compiled language> performance.
Some people still think Java is as slow as in 2000, but it is not. BTW, I always loved Moneydance as a good example of a good Java application:
http://www.moneydance.com/
I’ve used Netbeans on my PC (Celeron 1300, and I’ve had no perfomance problems with it) and I must say that it had the worst application performance I’ve ever seen. The garbage collector isn’t able to handle all the *garbage* on time, so Netbeans + the Java VM ended using as much as 200 megs of RAM! In the end, when the situation became critical, the application simply froze for about ten seconds while the GC was freeing up memory. This thing repeated every 5 minutes and drove me crazy.
Oh, and when I tried to run my app at my school with Pentium II-300 with 32 megs of RAM machines a simple 80-kilobyte app loaded for about FIVE MINUTES and with the Java VM used as much as 20 megs of RAM.
Native Java (e.g. GJC like the one used for compiling Eclipse in Fedora) is the answer!
Or why is it that sunone is so unbearable slow? If java apps are sooo fast when written well, then why don’t even Suns java apps perform good? You would expect that they do have the knowhow. I have never seen a single gui-Java program that wasn’t slow, even trivial ones. But to be fair, none gui programs indeed seem to be fast enough.
How dare you to mention Java?
My Visual Basic is much more efficient, fast and powerfull…
I agree with the fact that the speed discussion doesn’t do jutice to all the benefits of the Java language. The portability is a big plus, and to have every discussion focus on speed alone (which is relative to the task, as benchmarks also show Java as quicker) is a waste of energy and might deter people for the wrong reasons. This is not helped by the amazinf zealotery that is roaring in the programmer communities all over the internet.
Please keep discussions on topics and be reasonable. Try to find arguments that could weigh against YOUR OWN arguments, it will give you a better understanding. And don’t try to force your beliefs on other by stating nonsense or using only one argument. That not good for anyone. Remember it’s not politics or religion (no really, it’s not religion), and you can’t always be right.
“It always seems to be developers claiming that Java is fast on the desktop. You rarely hear the same from end-users. In general, I try and steer clear of installing any Java apps on my PC at home, and that means I’ve disabled Java in my web browser too!”
This means that your opinion about current Java performance is less than useless, since you’ve made it impossible to run Java apps on your machine, and you’re obviously not using any current Java apps. Try to form an opinion based on an actual point of reference, rather than the heresay on language war threads like this one.
Also, the comment you made about rarely hearing about good Java performance from end-users is less than useless as well, as end users usually have no clue whatsoever what the application they’re using was written in.
Go ahead and try it – ask a non-technical user if they know what programming language the application they’re using was written in. I’m 99.9999999999% certain that they’ll have no idea. Most of them won’t even know what C++ and Java are (other than Java being coffee). It’s only programmers who know and care.
And it’s only C and C++ programmers, well, the stupid, ignorant language war loving C/C++ biggots, who keep saying that all Java apps suck and that Java is slow and a memory hog.
The smart C/C++ programmers, who know that you should just use the best tool for the job, know that Java is great for some things, and C++ great for others, and that some Java desktop apps are indeed quite good, and that J2EE is very powerful and successful. Bjarne Stroustrup himself, who’s book I’ve read and think the world of, has never, ever bashed Java.
And smart Java programmers know that C++ is great for some things, particularily for game development, large commercial software, and lot’s of systems level stuff.
Finally, as has already been said by another poster here, benchmark tests are less than useless. They always are victims of the benchmarker’s bias and various skills/knowledge (or lack thereof) of the languages they are benchmarking.
Here are a few obervataions:
– Azureus normally occupies 32mb of ram on my computer, while firefox normally occupies 40mb (few pages opened)
– NetBeans has a lot of potential to be optimized
– Most people are not running java 5, which has the latest performance enhancements
– From my experience, ABC (a python BT client) has always been less responsive compared to Azureus and Bitcomet (a C++ BT client) always has the annoying list flickering bug.
– About java applets: most of them are not compiled under modern versions of Sun Java. Also note that java is running as a plugin in the browser and most browsers tend to handle plugin repaintings a lot less efficiently compared to the lightweight widgets it normally uses for web forms. Similar sluggishness can be seen on the Quicktime plugin as well.
– There are very few commodity desktop softwares written on java. Most in house softwares tend to perform poorly due to limited budgets, which means the developers hired may not have enough experience to use the multithreading facilities of j2se. They probably have no experience with Spin, Foxtrot or even SwingWorker.
– Try RSSOwl, Azureus, Freemind etc. on a daily basis for a while.
http://oddlabs.com/download.php – go on, I dare ya (yes, it is a Java game)
Java IS slower than a native application, and will bascially always be. However, Java provides a lot more for the both the developer and the end user which needs to be taken into account too.
One should note that the JIT compilers we have right now are not even scratching the surface of the possibilities with JIT. Here are a few obvious improvements that could be made:
– Permanent native code caching: right now, the JVM must recompile everything everytime you restart your java app. However, the java team is investigating the possibility of caching the compiled code to the harddrive. This means a large part of the application will not need to be recompiled the next time you start up the application
– Generics: The java5’s implementation of generics is rally a hack to preserve compatibility with older VMs. They could make much better use of the type information.
-Autoboxing: Yet another hack to preserve compatibility. It would be really nice if they can adapt the algorithms used in the smalltalk JITs to determined when boxing/unboxing really needs to occur.
This means that your opinion about current Java performance is less than useless, since you’ve made it impossible to run Java apps on your machine, and you’re obviously not using any current Java apps. Try to form an opinion based on an actual point of reference, rather than the heresay on language war threads like this one.
Um, did you actually read what I said? In the very first paragraph of my original post I stated I use java apps at work. What does that make your comment? Less than useless as well?
“Um, did you actually read what I said? In the very first paragraph of my original post I stated I use java apps at work. What does that make your comment? Less than useless as well?”
touche’
Anyway, I read the whole thing. But your experience with the Java app could be due to Java itself, or it could be due to poor coding/design by the programmers of the app, it could be due to the enormity of the app, or it could be due to many other factors. Just because one app, or a number of apps, written Java did not give you a satisfied experience does not mean that Java is weak.
By way of example, let me give a small list of applications written in C and/or C++ that I think suck:
OpenOffice – slow to load, slow to run, memory hog – about 95% C++
MS Office – bloated, buggy mess – 100% C++
MS Windows – swiss cheese security, unstable, buggy, overpriced – mix of C and C++
Oracle DB – although very powerful and scalable, it’s a huge resource hog and hard to use – C and C++
Now, would it be fair for me to conclude that C++ sucks just because I think these apps written in C++ suck? Of course not.
How well, how fast, programs written in different computer languages perform is definitively an important topic. Considering which languages help in improving, and which languages impede performance in a specifc situation is important too. Yet articles like these are worth next to nothing. Presenting a “Java is slow” Myth is a straw man argument. No serious Programmer will maintain a myth of this sort. Of course you can achieve fast programs with Java, at least for some sort of programs, and if you take some care. The same is true for every computer language I am aware of. After all, every programming language is just one representative of the same computational model, the same abstract machine. You could express a Java program as an C++ program, and vice versa (*).
It would really suprise me, if with the current high-quality Java VMs and compilers, almost all programs would perform bad. After all, Sun and other companies spend millions on improving them (Compare this to the mostly voluntarily developed implementations for numerous other languages).
So if you want to compare the “speed” of programming languages, Benchmarks are notoriously bad. But you can analyize which impact on speed the features of a language have. To achieve the desired result, which cost do the used features incur? How well can an implementation of the language optimize a given part of code? A meaningful comparision of languages, with respect to speed and efficiency, must discuss, why for a given programming problem, an implementation of the language which is discussed, is able or is unable to produce efficient code. This Article, and most of the Articles I read, whose claim is that Java is not “slow”, fail horribly to do this. Often the same arguments get repeated. So here: It is argued that the JVM (or the compiler) knows which processor it is running on, and can optimize accordingly. This is of course meaningless. It is irrelevant to the execution speed at which point in time the decision is taken to optimize for a specific processor. This article is little better though than the last one I read about the issue. Here the Author qualifies his statement, and mentions that this point is only true for commercial software. Nevermind that this is the wrong terminology, since the question is not whether commercial or not, but whether the source is available or not, but this qualification is also rather irrelevant to the discussion, because is basically only says, that if you deliver ill-optimized code, the code will not perform well. Well, one could call this tautological. Another of the arguments which do not help understanding is the point about knowledge which code gets included in the program. The article says a Java compiler will know which classes are loaded, and can base decisions about inlining on that. This is of course true (also the Author probably did not mean “classes”, but “implementation of classes”), but it can be true for C++ as well, for example, or for Ada or Pascal or whatnot. With these languages you also can make a decision about how much code the compiler gets to see when producing the binary program. In these notoriously bad Articles, the Authors do not only present the wrong arguments why a Java program should be faster, or can be faster as one written in another language, they also do presen phony reasons why there could be a performance hindrance to the Java version. This time its for example “JVM startup time”. The Author discusses if or if not the startup time should be included in Benchmark figures or not. As if this was an issue. I rarely do use Java, but I know that JVM startup is blisteringly fast, given the size of the JVM. Kudos to the Sun Programmers, they did great work (Especially given the fact, that at least the Hotspot VM is written in C++, and one can say that C++ has issues with program startup time on many architectures!). So I can not understand why alleged Java programmers apparently do not know that this is a non-issue.
I as a (mainly) C++ programmer can point out some issues where C++ language features impede performance. Other more knowledgeable people in the C++ world can even point out more. This is good, because this way one can work on the issues, and produce a better version of the language in the future. But Java people almost invariably get it wrong (at least if you read the slashdottet, osnewsed, random Java-Fan blog, etc… publications): They can not point out the real reasons why Java programs are faster in a specific benchmark, and they fail to recognize the true factors which are problematic with C++.
——-
(*): This may not be true of *really* all programs, but I suspect at least for most real world programs one could do.
I do not think the performance is such a problem, it is the awful look of each and every swing gui. The themes suck, and the fonts too (there is no subpixel hinting).
on may laptop (500mhz, 192mb ram) you can watch netbeans redrawing the window line by line.
I know that my lapop is slow, but even doing 3d cad in software-opengl is faster than this…
All 3 of your bullet points are what .NET/Mono does now.
Actually, look at Java 7 to get the big VM changes. Supposedly, Java 7’s VM will be a lot more friendly for dynamic languages.
“java -server” makes wonders to performance, providing you have a good amount of memory.
I know. Swing looks horrible on LCDs. I got into with one of the Java2d guys over at Javalobby, where he claimed that Swing fonts weren’t bad and that it has not impeded Java growth on the desktop.
No wonder Sun and Java has had problems on the desktop when their Java2d guys have their head in the sand.
Look for a Mustang snapshot with subpixel rendering in it to be released this week. Probably tomorrow or friday.
Hi Martinus, Do you think our Swing-based app looks awful?
http://xerto.com/images/screen-shot.png
If so we’d definitely appreciate any feedback on how to make it look better.
I agree with you about the font rendering. Looks like that will be fixed in Mustang which is nice. In fact, if as previously mentioned that’s fixed in an upcoming preview build, I’m very keen to try it out.
I agree with you that there are a lot of poor looking Swing apps out there, but then again there are a hell of a lot of poor looking non-Swing apps too IMHO.
“Hi Martinus, Do you think our Swing-based app looks awful?
http://xerto.com/images/screen-shot.png “
Wow, looks fantastic. Really, that is one nice looking interface. And it should shatter to pieces the notion that Swing GUIs look bad.
Thanks JeffS, glad you like it.
It’s not to say that it doesn’t take a reasonable amount of effort to get a good looking Swing app, but I think that’s true of a lot of GUI frameworks, and at least Swing is readily customisable.
Someone earlier mentioned that C/C++ was a general purpose language.
That may well be, but C/C++ slowly but surely getting relegated into the specialty role, whereas Java is becoming the general purpose, first to reach for tool.
As has been mentioned here, Java is “fast enough” for a wide range of applications, and continues to get better and better, through a combination of JVM improvements, library improvements and new code.
You can pretty much do anything but write device drivers in Java today. From monster applications running on huge clusters on down to handset apps on your cell phone, the base platform and the JVM itself has proven to be resiliant and capable.
You can do all of that in C/C++, of course, but if the performance metrics work out, you can do it easier and faster in Java through a combination of simply being an easier language to use combined with leveraging the VAST amount of Java based infrastructure available today.
Java’s umbrella is huge, and getting wider, while C/C++ is getting crowded out into more niche areas. Once Java survived Applets and made its big bang on the server side (where WORA is working pretty good at the JVM level, and creeping up into the J2EE server space as well with portable WARs and EARs) and is beginning to make a larger impact on the desktop, meanwhile having its foundation consistently and incrementally improved (from better JITs, better libraries, things like the MVM, etc.), the pain and expense of developing in C/C++, fighting library and binary issues, etc. is looking less and less attractive.
C/C++ still has a very strong foothold in the commercial consumer marketplace, but behind the scenes, on the server and on corporate desktops, which is arguably a larger market in terms of $$$ into software, Java is going strong and growing.
In many circles, C and C++ have to justify their use over Java rather than the other way around.
Those circles are getting bigger.
“Thanks JeffS, glad you like it.
It’s not to say that it doesn’t take a reasonable amount of effort to get a good looking Swing app, but I think that’s true of a lot of GUI frameworks, and at least Swing is readily customisable.”
No problem. Is your software available for free trial download? If so, what are the hardware requirements?
That app looks nice. All you need is for Mustang font improvements. I think the green looks good. Nice “cool” colors.
In my opinion the article is trying to defend java because it is flawed. I don’t understand what it takes for java to be snappy. On the applet front esp in web browsers I dread applets, after all from a layman point of view applet does nothing more than have some fancy animation. However the important point is if java bloat takes sometime to load before showing the artifacts I’d rather block it. The point of java being memory freindly, aw c’mon fire up azureus and look in the task manager. If the whole point behind java was platform independence it is a failure.
he point of java being memory freindly, aw c’mon fire up azureus and look in the task manager. If the whole point behind java was platform independence it is a failure.
While you are at it, fire up firefox and open a few pages. See how much memory firefox hogs. Also, make sure you also open up Microsoft Word and open a document with 5+ pages containing a few charts and equations and see how everything goes.
The threading problem is a very common problem. Unfortunately, j2se doesn’t include a readily available solution to solve this problem, unlike VB, which provides doEvents.
“No problem. Is your software available for free trial download? If so, what are the hardware requirements?”
It’s not available just yet but it will be as soon as we enter our beta testing phase. I can’t give an exact date for that just yet though sorry.
Hardware-wise, it should run fine on any PC from the last few years but you’ll obviously get better performance if you have a newer PC with decent graphics acceleration and a reasonable CPU (for instance if your processor has hyperthreading it’ll take advantage of that, which is quite handy if you’re regularly cataloging large amounts of images).
‘That app looks nice. All you need is for Mustang font improvements. I think the green looks good. Nice “cool” colors.’
Thanks. Yeah I’m really looking forward to the font improvements, along with the proper support for backbuffering which is already in the current builds.
The colors for the selection, the filter panel blocks etc. are based on the system colors with hue,saturation, brightness adjustments so they vary depending on your color scheme. You get a nice coolish blue with the default Luna theme on XP for example. The other neutral colors are fixed though. Our general aim was to not let the interface draw attention from the main focus which is the images themselves – hence the subdued color scheme.
Tomorrow or Friday should be the release of the Mustang B39 build that has the subpixel rendering and some other stuff (like respecting desktop AA settings).
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/mustan…
Scroll down to the Java2d section.
If Sun cares about the desktop, they’ll backport this to Java5 in a service release.
I used to avoid any program that was developed in Java, until I tried FreeMind. I cannot think of any part of the interface of FreeMind that feels sluggish in any way. In fact, if it was not me who installed it, I would likely not even realize that it was a Java program.
Since installing FreeMind I have tried several other Java programs and have found many (but not all) to have similar speediness in the interface.
It seems to me that this Java is slow preception is a myth.
how much more memory just to make a java app look nice?
it always seems that java eats memory willy-nilly, sometimes I am doing nothing at all and a java app will still go up and down with memory usage as well as processor usage… then if I actually use the app it continues to fluctuate…. I dont get it….
I just think everyone is always interestd in using a new language because it is new and going to be the big thing and it takes a few years to realize it isnt much better if at all then what we were previously using, diffferent yes but not all that better….
We just need more java programmers who are dedicated to making professional-quality softwares. The user experience often have nothing to do with benchmarks: They have more to do with the dev’s skills, knowledge and dedication.
>Hi Martinus, Do you think our Swing-based app looks awful?
>http://xerto.com/images/screen-shot.png
>If so we’d definitely appreciate any feedback on how to make >it look better.
Looks very nice indeed. What development setup do you use, specifically do you use an IDE for your Java work?
Java by far is the best programming language out there. It is platform independent and has a rich of libraries. I do agree that Java is slower than C++ in some instance, but with the development of new JIT, it will eventually close the gap between C++. With that being said, the ease of developments and portability will out gain its speed issue.
In my line of work, I used java for real time signal processing and distributed application. Since I don’t sometime don’t my client Operating System, writing it in Java make sense.
first, well-written java apps will always run slower than well-written native compiler apps. not much technicalities or benchmarks must be discussed to realize this. java apps goes through the jvm before the machine can execute it. natively compiled apps are directly executed. but then, well-written java apps can run fast enough for end-users.
second, java is proud of its write-once, run anywhere ability. but then again it does not matter much for at least two reasons.
1. a company normally uses entirely the same OS for better performance and easier maintenance, so that the ability of their java-written apps to run on different OS/machine is of really no use to them.
2. native compilers can offer write-once, compile anywhere, without changing the codes (consider free pascal at http://www.freepascal.org).
so the bottomline here is, don’t tell me that java is slow. don’t tell me that my compiler does not offer “write-once, run anywhere” ability. but tell me, how well can you write codes?
OK, I’ll say it again: subpixel text antialiasing is NOT critical for java on desktop.
FYI: ClearType is not turned on by default on WindowsXP, even on notebooks. Guess why. (hint: not everybody likes it, another hint: it slows your system down because it’s not accelerated on windows xp). Also, do a search on msdn for problems with cleartype and MS office – people complain that text looks fuzzy and unreadable (especially with smaller font sizes).
So Java2D’s subpixel text antialiasing is unlikely to be backported to 5.0 (unless Lumbergh who complains so much will buy a support contract and file an escalation =)
Note that I’m not saying that there are no font rasterization problems with Java2D, we know about them and some of those fixes may get backported from 6.0 to 5.0 updates, my point is that LCD text rendering is nice to have but not critical. Regular AA would do just fine for most people _even_ on LCDs. And that’s another reason to spend time improving text rasterization..
Having said all that, yes, the subpixel rendering will appear in mustang b39 (along with tons of other juicy stuff), and it will be enabled by default, so if your desktop “text smoothing” is set to ClearType then text in most swing apps will be rendered with LCD AA, on Windows and Gnome.
In case you don’t know where to get the latest 6.0 build:
https://mustang.dev.java.net/#download
Thanks,
Dmitri
Java2D Team
The problem is not Java being inherently slower or more memory-hungry than C/C++ or whatever.
The problem is that a whole generation of programmers has been raised to believe that it’s OK to write slow, bloated software. It’s a culture thing. Anyone raised on C/C++ in the early 90’s would have a large awareness of performance issues, optimisation, etc. etc. Anyone raised on Java/.NET would not; they’d be thinking objects, garbage collection, etc.
Java itself is not much more slower or bloated than any other runtime; it’s just the mindset of the people who code its apps. (Also, the Java runtime can in certain circumstances be faster than a C/C++ runtime, since it cam perform dynamic runtime optimisations, whereas C/C++ optimisations are static at compile-time. But that’s a completely different debate.)
General rule, and it does not matter which language you use, if something is to slow, start to revamp your algorithms and patterns, do profiling, in most cases the language is not to blame there (after all java basically does what GTK2 and other Toolkits do, draws its own widgets at basically the same speed as C written GTK2), but in 99.99% of all Cases I have encountered in the last 15 years, the algorithms were. Often it is an unneeded O(n²) or even worse O(n³) at places where you could push it down to O(log n) with a little bit of knowing how to use data structures and changing the algorithm, often it is excessive object allocation (typical problem from people who come from the C++ side of things and suddenly are in the we dont have to call delete anymore heaven)
The main problem with Swing applications is, that most people are to lazy to switch on an alternative look and feel, they dump it onto the user with the awful metal look and feel, many programmers are not aware that they have to push longer operations into the background. That is mostly a problem from people who come from the windows side of things, which also blocks at longer operations, but not the control redraw, so that you get the impression that redraw happens instantly, the application just blocks, while Swing gives the impression that it crashed or is dog slow. Sun should push the workers and Foxtrott stuff excessively into the documentation, to fix that problem.
“I do agree that Java is slower than C++ in some instance, but with the development of new JIT, it will eventually close the gap between C++”
I don’t buy this. I think there are fundamental reasons why Java is slower. Those reasons won’t go away without deep philosophical changes Java. The biggest issue I see with Java is that it does EVERYTHING itself, and it does it it’s own way. This is seen by developers as a benefit because the libraries are all portable and available on other operating systems but for the end user it’s a pain. Here’s why:
If there’s a library in your OS somewhere for, for example, rendering fonts or tcp/ip communication, odds are you have it loaded and in memory all the time since those functions are regularly used. When you fire up a python application that does these things, odds are it was linked against the same libraries as your file manager or your web browser and those libraries are already in memory somewhere. Since most modern OS’s have the concept of shared object files (dll’s work that way) the loading is almost instantaneous since both applications end up just sharing the one memory image of the code. When you fire up a Java application, however, it has it’s own libraries for doing all these things and it therefore needs to load them all adding tons of disk IO and memory allocation and swapping to the application startup. Now, you might think the answer to that problem is that you simply need to use more things written in Java. This isn’t quite the case either though since Java applications all JIT their code instead of linking with shareable object code so the OS doesn’t have visibility into the fact that the code is the same and could be shared.
The other big issue I see with Java is all the compiling. People love that huge standard class library but in the end, if you need to compile 50 different libraries into machine language just to get your application to run, it’s going to take some time. It will also blow out your RAM caches and disk caches with all the compiling activity. This adds to the “resource hog” feeling of Java and again, this is a hard thing to fix. If they would turn the Java libraries into pre-compiled sharable object code they could fix this. I don’t see that ever happening.
I like the idea providing developers with a standard interface to common OS functionality across platforms but Java pushes this to an impractical extreme. Their unhealthy obsession with not allowing anything OS specific is the cause of much of Java’s pain. They try to treat Java as the OS instead of the OS itself. Instead of treating it as an OS, they should be treating it as a development platform for making native applications since, in the end, that’s exactly what it is.
Just remembered this old link comparing the memory usage of Java/C# (Mono)/Python/Perl.
http://tirania.org/blog/archive/2005/Feb-09.html
oh .. and need i mention how nice it is (in C#) to not have to care about the difference between int/Int, long/Long etc. and just write “int i = 2 + new int(2);”
OK, I’ll say it again: subpixel text antialiasing is NOT critical for java on desktop.
You are right, and thankfully we have SWT for those that want nice looking fonts. But I’m sure Gnome and KDE users would be perfectly happy without subpixel rendering/hinting on their LCDs.
FYI: ClearType is not turned on by default on WindowsXP, even on notebooks. Guess why. (hint: not everybody likes it, another hint: it slows your system down because it’s not accelerated on windows xp). Also, do a search on msdn for problems with cleartype and MS office – people complain that text looks fuzzy and unreadable (especially with smaller font sizes).
So now you’re trying to argue that ClearType is not good. It’s fuzzy…there are problems. At least you have the option of using it or not. With that attitude its no wonder that its taken so long to address this issue. At least people have alternatives (SWT)
So Java2D’s subpixel text antialiasing is unlikely to be backported to 5.0 (unless Lumbergh who complains so much will buy a support contract and file an escalation =)
Swing isn’t the only game in town.
… my point is that LCD text rendering is nice to have but not critical. Regular AA would do just fine for most people _even_ on LCDs
In your opinion it would “do just fine”. And you’re right again, it’s not critical for Java because we have SWT.
What about Swing on OSX? It looks great.
I’ll download the B39 build today or tomorrow and check it out.
oh .. and need i mention how nice it is (in C#) to not have to care about the difference between int/Int, long/Long etc. and just write “int i = 2 + new int(2);”
Oh, java can have that as well, there are preprecessors for that
About all the comments: Just a load of crap! Both pro and conn still stick to the same good old excuses to have an opinion about java, mumbling about a few details. Come om, look at the whole picture before making up your mind about how great java is, or how much it sucks. I guess, in the end, it somewhere in between. I could just as well start praising or bashing any other programming language…
oh .. and need i mention how nice it is (in C#) to not have to care about the difference between int/Int, long/Long etc. and just write “int i = 2 + new int(2);”
Oh, java can have that as well, there are preprecessors for that
Didn’t know that. Gave up on Java a few years ago, started playing with it again recently, but got kinda dragged into C# instead, and was very positively surprised with how well the language works compared to Java.
In my heart i want to write all software in C (old school C programmer), but the productivity gain in higher level languages like Java,C# and Python is just too big to be ignored, and i’m more than willing to accept a small performance penalty in exchange for that, but the larger memory usage, slower load times and general “lag” of most java applicatinos (azureus, eclipse, jedit to name a few) is just too high a price to pay.
Someone mentioned that python apps actually loads faster / runs better than java apps, and I must agree that this is the case… on Linux anyway.