Skip to main content

How to Make Java Suited For Desktop Apps

Posted by flozano on April 1, 2005 at 8:01 AM PST

How to Make Java Suited For Desktop Apps.

Even if you manage to create a terrific first Swing app for your users, the second one will probably hurt you.

Joshua Marinacci's asked on his Blog Why don't you ship Swing apps? and suggested some usual reasons like deploying the JRE, Swing API complexity and corporate focus on web apps. I'd like to add and discuss one more reason:

- No class / code sharing

When you develop apps for in-house use it's almost certain there will be users who run many of those apps at the same time.

For the first one you strive to become a good Swing programmer, get all fancy third-party libraries from JNDC and JGoodies, bundle the JRE (or deploy it on all clients by using you preferred enterprise management system / login script hack) and get the work done, hoping the cross-platform compatibility you get will pay for the extra effort, specially with so many new Linux desktops out there.

But when it comes the second application, it'll load another JVM and spend another 25+Mb with standard and third-party libraries. There's a reason all GUI platforms are based on (1) OS-Level code or (2) Shared / Dynamic Link Libraries.

I remember using the first Java installer for Oracle 8i, I needed more RAM to run the installer than to run the development and sometimes the production servers, just because the installer called two or three other Java apps for creating the database and configuring networking parameters.

It should be easy to create a "Java Launcher" that justs calls each app main method and runs everything as different threads inside the same JVM, but Swing developers screwed this up by creating hidden threads and requiring us all to call System.exit(0) to finish the application.

You can see almost every other GUI toolkit for Java lets you control the event loop and would not suffer from this problem. Check, for example,