Airlan San Juan's Blog

Are Java desktop developers giving Java a bad name?

Unfortunately, I'm not kidding. When dealing with antagonistic parties, most recently in the Blu-ray arena, I noticed that their examples of bad Java applications almost always revolves around bad experiences with either Java desktop applications or applets.

We all know why applets got such bad reputations, but there really is no good excuse for Swing and the like to continue to give a sour aftertaste to users. I myself use Netbeans regularly, and although it has improved by quite a lot, there are still times when the thing slows to a horrid crawl when I use anything smaller than a 1 GB, 1.8 GHz box.

I deal with Java ME on almost a daily basis, and although the target of these applications are devices several times less powerful than desktops, I have yet to find a user who has complained as vociferously about them. Is this because user expectations for these smaller devices are less than their expectations for the performance of desktop applications, or is it because developers targeting more powerful machines have become unconcerned about code optimization, something that is foremost in the minds of smalljava developers?

Comments

• It seems to me that developers in many languages are targeting todays (or even next years) new machine and ignoring the more limited capabilities of a 2 or 3 year old model. In fact I have heard a Microsoft executive expound this as a deliberate policy --- i.e. it is intended that new software run like a dog on older machines because those users probably won't pay for it anyway.
  A recent upgrade of a grahics card driver swallowed an extra GB of disk space and the associated control application runs like dog on my 4 year old 512MB home machine. It was implemented in .NET.

  Posted by: mthornton on June 07, 2007 at 01:15 AM

• it's not so much policy to have software run slower on older hardware as to not optimise for performance unless the software runs unacceptably slow on current hardware.
  Different reason for the same end result. And hardly restricted to Microsoft (it's just most visible with them as their software is most likely to affect what you're running either directly (because it's their software) or indirectly (because it uses their libraries under the hood).
  But the problem goes a lot deeper. Schools and universities no longer teach even basic defensive programming for performance, leading to an entire generation of programmers who don't know what the performance penalties of their decisions are (and in fact often state that performance optimisation is not important because people will get new hardware anyway).
  This is somewhat less relevant in the Java arena, but here too way too many people don't care about the performance of their applications and/or don't know what to do to make sure their apps perform reasonably well. And it just so happens that it's a lot easier to write poorly performant code using AWT and Swing than when it's something like a servlet.

  Posted by: jwenting on June 07, 2007 at 02:34 AM

• "And it just so happens that it's a lot easier to write poorly performant code using AWT and Swing than when it's something like a servlet."

  Especially since the developer knows the target machine for that servlet and the desktop developer probably is only running the latest high performance box ;-)

  In fact I have heard a Microsoft executive expound this as a deliberate policy --- i.e. it is intended that new software run like a dog on older machines because those users probably won't pay for it anyway.

  This doesn't seem to make sense because most users do not have the latest hardware....especially now that PC growth is maturing.
  

  Posted by: asj2006 on June 07, 2007 at 05:48 AM

• One problem I have with newbie developers is their penchant for premature optimization. Because of that, I have doubts that schools are de-emphasizing optimization, but there's really not enough evidence to argue the point.
  I would say, however, that if universities are not teaching defensive programming, that's okay. The real failure is not teaching profiling, analysis, and creating the expectation that it should be part of every development process.
  

  Posted by: erickson on June 07, 2007 at 08:30 AM

• This doesn't seem to make sense because most users do not have the latest hardware....especially now that PC growth is maturing.
  Hey its Microsoft, it doesn't have to make sense! The theory was that most software is sold with new machines or for near new machines. Not being in sales, I have never known how true that is or whether it is changed in recent years.

  Posted by: mthornton on June 07, 2007 at 09:26 AM

• jwenting: leading to an entire generation of programmers who don't know what the performance penalties of their decisions are

  
  Indeed. And Sun has hired them all.

  The problem does not start with Swing, AWT, Qt Jambi, Thinlets or or whatever GUI junk an application developer uses. The problem starts with the way Java desktop applications are installed. It continues with a lack of desktop integration and cumulates in the fsking, gawd-dammed VM startup time. You click on it and nothing happens others than that the drive spins up or the Etherned LED starts blinking wildly and the CPU burns through billions (yes, billions) of CPU cycles. Not getting it up is the worst thing that can happen to you in bed and on the desktop.

  When you have the problem in bed you can ask your doctor. When you have the problem on the desktop you are about to encounter the arrogance of the Sun Java developers who just couldn't care less since a decade.

  Of course, once the beast has come up slowly and starts to do some work things don't get much better. A Java desktop application can't access the desktop other than drawing some rectangular boxes (aka windows) on the screen. It can't register a datatype. It can't place or remove an icon or a shortcut on the desktop or quick launch bar (after ten years an application can finally add an icon to the system tray). It can't add or remove a desktop menu entry. It can't access the devices connected to the desktop computer, it doesn't know the difference between removable and non-removable media and doesn't know about media insertion or removal. A Java application in general behaves like an alien on any desktop. This is not a PLAF problem. It is not a problem of the imaginary lack of a GUI framework. It is the problem of a total lack of desktop integration.

  And it came to this because it was much more important for Sun to add new useless features like generics to the language than to fix real-world problems. I wish half of the energy of the Sun closure fanboys would go into desktop integration. Or all of the effort wasted on generics would have gone into desktop integration.

  Of course there are also issues with the GUI toolkits. SWT is incredibly slow on anything but Windows. Swing has incredibly bad components like the dreaded JFileChooser, the image APIs, the font API (in case you manage to find something that can remotely be interpreted as a font API), or the printing APIs. And of course AWT was and is a joke.

  In the light of all this, what should a desktop application developer do? Polishing a turd is just not fun. So you start hacking JNI code and probably spice up the application with a special PLAF. Writing a Java desktop application is an incredibly nasty job. You do it fast, don't care about the finer details and try to get rid of it as soon as possible.

  Posted by: ewin on June 07, 2007 at 10:15 AM

This work is licensed under a Creative Commons License.