JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 051 contents

The SWT/Swing discussion waffles on. Gosling comments, Eckel counters. ( http://onthethought.blogspot.com/2005/02/gosling-on-swt.html) For those of us who looked at emulated versus native all through the 90's, there is nothing new, not even the arguers inability to decide what we already learned 10 years ago: native is better for some projects, emulation is better for others.

Why am I joining the waffle? Because of the performance fud. I'll state right up front, a Swing app can be blazingly fast. There is no doubt about it, get a Swing performance guru in and he'll manage it - or find a bug trying. And it's likely that if you tune it on one platform, it'll already be fast enough on most of the other platforms. Likely, but not guaranteed.

An SWT app can be blazingly fast. You probably need to put less effort in tuning it to get there. But more effort in making it fast enough (or even working) if you need to support multiple platforms. So what do you need? Evaluate your requirements, ignore the entrenched positions of the advocates because they really have nothing new to say, and choose what is most appropriate for your project. Java is here to serve your requirements, not the other way round. Both Swing and SWT are valid solutions for those requirements.

A note from this newsletter's sponsor

In the newsletter we list our usual raft of articles, news and tools, and we provide our usual sections. Kirk gets us a scoop on the new TheServerSide editor, and covers memory leaks, avoiding generating DOM when using XML, 6.0 performance, and much more in his roundup; our Question of the month re-visits the overheads imposed by the volatile and synchronized keywords; and we have many new performance tips extracted in concise form.

A note from this newsletter's sponsor

News

Java performance tuning related news.

• The new features and tools in BEA JRockit 5.0. JRockit has always been slightly ahead of the Sun JVM in performance management, and looks like they have kept that lead.
• I'm increasingly seeing the 1.4.2+ overheads of reflection generated classes, which is why I've included this older blog item as news.
• And here's another reference about reflection generated classes - worth bearing in mind for performance implications.
• Interesting details on problems of copying big files in Java in Windows.
• 5.0 New GC ergonomics
• XSLT is way faster using Java 5
• GCJ performance looks very good

A note from this newsletter's sponsor

Tools

• Utility and Framework for timing and animations.
• JBossProfiler
• Intersperse Manager enables production monitoring
• Hyperic HQ production monitoring
• JDBInsight 3.0 released
• WebSphere Thread analyzer

Recent Articles

• Monitoring your Java applications' Windows memory usage (Emma Shepherd, Martin Trotter, Caroline Maynard, Matthew Peters/IBM).
• Session Replication in Tomcat 5 Clusters (Srini Penchikala/OnJava).
• Eliminate caching in service locator implementations in J2EE 1.3 (Bobby Woolf/IBM).
• Selecting performance tools (Ruth Willenborg/IBM).

Jack Shirazi

Back to newsletter 051 contents