posted by Andy Roberts on Wed 1st Jun 2005 16:22 UTC

"Java performance debate, Page 3/3"
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.
Table of contents
  1. "Java performance debate, Page 1/3"
  2. "Java performance debate, Page 2/3"
  3. "Java performance debate, Page 3/3"
e p (0)    150 Comment(s)

Technology White Papers

See More