Joshua Marinacci's Blog

Why don't you ship Swing apps?

Time and time again I hear that there are no Swing apps (or no good swing apps). We can come up with lots of excuses and explanations but that doesn't get us any closer to having more Swing apps. So I'd simply like to ask all of you. Starting with the assumption that all of you are Java developers in some fashion or another, but not necesarily Swing developers, I want to ask you:

What is keeping you from shipping a Swing application
(or a desktop java app in general)

• Is it making sure the user has the JRE / right version of the JRE?
• Is it that your Swing apps are too slow or clunky?
• Is it that you don't know how to write Swing? Are you more familar with webapps?
• Is there some crucial feature missing in Swing that forces you to go with another technology (.NET, Flash, native app?)
• Something else I've completely missed?

I really want to know. I have my ideas but there is no substitute for hearing directly from the developers in the field building (and shipping) real apps.

Thanks,

Comments

• I do ship a swing app (Nuance V-Builder), and our customers are quite happy with it.However, I ship it with a bundled JDK, which is a bit of a shame.

  Posted by: richunger on March 31, 2005 at 11:41 AM

• How do you ship it? Why did you need to bundle a JDK? I'm assuming that this is on CD?

  Thanks,
  - Josh

  Posted by: joshy on March 31, 2005 at 11:43 AM

• We haven't shipped any Swing apps chiefly because the word on the street (or, should I say, in the boardroom) is that companies want web-based applications.
  I don't know if this is because they want no client installation or central management or whether they just think webapps are "the thing" at the moment.

  I hope Webstart will keep getting better and soon we can deploy rich client apps almost as easily as webapps.

  Posted by: grlea on March 31, 2005 at 03:57 PM

• 
  At the moment I'm hard at work building an SWT app that I'm hoping to ship as a commercial app later in the year. I initially tried building it with Swing and decided that:

  I'm just not smart enough to understand Swing.
  I'm just not willing to put in the effort to make Swing look decent on all platforms. Even making it look good on Windows was hard work.

  I've blogged about some of my experiences with all this.

  
  Swing could learn a lot from the pragmatism in the SWT api - it's a very easy API to pick up - but they had the advantage of a clean start. And with JFace I get a much more straightforward MVC, with the native look and feel appeal. Add to that a big performance gain on 1.4 JREs, access to the tray/baloons/and all that windowsy stuff and.. well.. it was a compelling choice for me. YMMV.

  
  What SWT doesn't solve for me is the whole deployment thing. I'm still going to need to bundle a JRE with my app - just to ensure a decent user experience in the install process - for instance a single downloadable .exe for the install... rather than getting to the install screen and finding a "Oh. Yeah. You need to download this other 13Mb runtime before we can go any further..."
  

  Posted by: glen_a_smith on March 31, 2005 at 07:18 PM

• In my opinion, the major reasons the keeping me to ship Swing App:

  Is it making sure the user has the JRE / right version of the JRE? Yes, It is because even with the help of WebStart, we still need to install the JRE and the size of JRE is very large. Is that possible to reduce the JRE file size?

  
  

  Posted by: tmky2k on March 31, 2005 at 07:31 PM

• As long as JWS continues to stay broken it will be incredibly hard for Swing applications to gain traction in the marketplace. JWS will remain broken until the JWS developers come out of their white tower and listen to the developers/corporations who are trying to deploy Swing applications.

  F.E.
  1. the JWS socket service.

  Also note that Sun is shooting itself in the foot by building libraries that can not be shipped as an __unsigned__ JWS application!!!

  F.E.
  1. java.util.Logging. Can you believe they designed Logging so badly that you can not use it in unsigned JWS?
  2. Groovy (Sun pushing this in all of the scripting JSRs) does not work in unsigned JWS.

  Not to be undone, lots of third party libraries shoot themselves in the foot by not following a simple rule: don't use System.getProperty(). F.E. JGoodies and XmlBeans. Neither of those work properly or at all in unsigned JWS.

  I see lack of knowledge as part of the problem. Not everyone knows the limitations of the unsigned JWS environment.

  In the case where Sun knows about the unsigned JWS limitation but doesn't care about it and refuses to work within that environment (Sun pushing Groovy) I'm not sure what can be done.

  Posted by: markswanson on March 31, 2005 at 08:25 PM

• 
  I don't ship Swing applications because they look malplaced and foreign having their own look and feel. That simple.

  
  This is really more an organizational problem at Sun than a technical problem; the solution is well-known (and has been since 2001, I may add) and the situation could be fixed in the next release if someone at Sun just realized the problem.
  

  Posted by: rkaufmann on April 01, 2005 at 12:41 AM

• It is always a good sign when they ask for feedback :)

  I don't have any trouble figuring out how to use Swing but there are a few things that bug me:

  There are three components that I see as the core weaknesses of Swing:

  - JToolbar: When you interact with JToolbar e.g. tearing it loose etc. it does not behave anything like typical Windows toolbars, nore does it look like one. You should use the NetBeans 4.0 toolbar as a good example of how a toolbar should look and behave.

  -JMenu
  Swing menus always take longer to repaint than native apps - esp. on slightly older hardware, the Windows look and feel consistency of Swing menus is very poor (lack of shadow, spacing etc).

  -JFileChooser
  This is one of my pet hates. Swing lets me customize the file chooser - great! Most of the time I don't need this though and the AWT file chooser would be a better choice, but I can't use the AWT filechooser because it doesn't support file filtering on Windows and you cannot select multiple files or even set the location of the dialog (I can do all this with SWT). When you open folders it makes the Swing app flicker in the background.
  So I end up having to use the Swing file chooser anyway. The performance and look and feel have improved a lot over the years. Unfortunately it is still very different from the Windows XP file chooser esp. for right-click menus and views.
  Performance is also an issue. I have a work folder with about 900 or so files. When I navigate to this folder using the Swing file chooser it takes nearly half a minute to open. With the native file chooser this takes approx. 2 seconds.
  (BTW I am using a 3.4GHz P4 with 1Gig RAM, Win XP Pro SP2 with jdk1.5.0_02)

  -Text is not smoothed in Swing, which makes some text look jagged.

  -Not really an easy one to fix, but Swing apps use 25MB (not heap, but total use) for even a fairly trivial app (though not such a big deal these days). They also take longer than native apps to startup (this does make a difference). Compare a cold start of Swing notepad to a cold start of windows notepad.

  -Until tiered compilation and the merging of the client and server VM's desktop developers always get a slower VM to use.

  Although I find Swing quite easy to use I found SWT even easier (I still prefer and use Swing though). With SWT you know where all the fields are: SWT.CENTER, SWT.LEFT etc. With Swing these types of constants are stored all over the place. Creating JMenuItems with Swing esp. with shortcuts and mnemonics is a pest. You have to type and type and type. Perhaps you should consider having a Swing class with factory methods for creating components and storing constants.
  

  Posted by: jdolphin on April 01, 2005 at 01:02 AM

• Looks like my formatting got lost :(

  Posted by: jdolphin on April 01, 2005 at 01:03 AM

• - Is it making sure the user has the JRE / right version of the JRE?
  Yes this is a problem, cause if users are forced to install a JRE, they have no idea about what Java is (nor should they), and this makes always a negative image on the product. Most normal users think that Java is something evil that must be deactivated, cause you'll have problems with the browsers.
  - Is it that your Swing apps are too slow or clunky?
  This is also a problem. One needs to be really a Swing expert to be able to make fast and 'non-clunky' applications. Swings is very nice good and flexible, but very hard to do simple things by beginers in short time.
  - Is it that you don't know how to write Swing? Are you more familar with webapps?
  A lot of users do not know how to write GOOD Swing - there are only a few good books about (most of them just map the API). Webapplications are easier, and in a lot of cases when Swing would be better, still the web version is used (e.g. intranet applications are very good for Swing, still 90% of them are made as webapplications).
  -Is there some crucial feature missing in Swing that forces you to go with another technology
  Fast startup projects for Swing NonExperts. A Swing expert will always choose Swing, but the problem is that most programmers that have the choice in new projects are not Swing Experts.

  Posted by: amohombe3 on April 01, 2005 at 01:12 AM

• Two reasons:

  1. There is no simple application framework available. And no, Netbeans is a great application framework, I am talking about a simple on that you could use for a Winzip clone or some similar small application.

  2. The look and feel is just not good enough. The Windows Look and Feel neither really looks nor feels like Windows, Metal and Ocean are plainly unacceptable, Synth is vaporware (it just doesn't exist, does it?), and I don't want to start talking about the font rendering in Java5. Just implementing all the bugfixes from the Winlaf project ( https://winlaf.dev.java.net/ ) for Mustang would help a lot.

  Posted by: jansan on April 01, 2005 at 04:42 AM

• In my corporate life, I found that it was a strong dislike of installing and maintaining anything on client computers. It's hard enough to manage Corporate Obedience Win-Boxes with all the malware and updates without having to, y'know, have actual software on them. The big win of the web application is that it only needs to be installed and maintained on a server. I actually worked on a project to port a Swing client to a web app. Why? Because in the local client-server case, that meant going from maintaining one server and 15 clients, to maintaining one server (which our company could do remotely).-Chris (invalidname)

  Posted by: invalidname on April 01, 2005 at 06:20 AM

• I love Swing and Java, there is no doubt about that. I have a few complaints:

  JFileChooser is too slow compared to the native AWT file chooser. It doesn't support views. I find this very annoying because JFileChooser is part of a lot of applications. The AWT FileDialog doesn't support file filters, can you fix that?
  Application startup is still slow compared to C# for example.
  Memory footpring gets a lot especially when dealing with large images
  I can't wait to see JDNC et JDIC be part of the JDK. These will put Java on par with other native programming languages.

  Posted by: carcour on April 01, 2005 at 06:24 AM

• We ship a Swing app on a CD with a bundled JRE. Webstart and bundling are the only two reasonable deployment mechanisms available from a QA standpoint. No matter how much you try to write code for a generic JRE, you are probably only testing against one. I've been working with this particular app since the 1.3.1 JRE. Every new JRE has broken something.
  I suggest that Sun support a more unified approach to deployment.

  JNLP should be well supported with and without a web server. It should be trivial to change distribution from the web to a CD.
  JNLP should support launching from disk. There is no reason anybody but developers should need to turn to Ant as a cross-platform launcher.
  An extension to JNLP that will allow easy distribution from a network (ala Nutella), rather than from a particular server. The goal is to minimize the impact of down servers and connectivity problems cheaply for those that don't have time and money to otherwise provide good solutions to these problems.
  Users should only need to install one JRE ever. Once one JRE is installed, it should automatically install older and newer JREs as they are needed and available. Only the initial installation should require administrative priviledges.
  Sun should support a mechanism that allows an app to ship with a small JRE installer stub. The full JRE can then be downloaded only if needed.
  

  Lack of well documented application frameworks is another important problem, but only for apps large enough to need them.

  Posted by: coxcu on April 01, 2005 at 06:44 AM

• For the last 6 years I worked for an IT German company as "team leader" and we developed several Swing apps. The biggest one was an small ERP system (took 8 people 1.5 years of intensive work).

  From my point of view there are several big problems:

  The most important one is that we need more componnets, specialy data-awere beans. It is simply impossible to create a desktop app without using Borland (or other lib) data-aware beans.

  "Metal" looks horrible, and the new one in 1.5 does not look much better. It does not look professional.

  There is not a good installer/deployer that will take care of everything excepts perhaps WebStart (we used it)

  
  Other minors inconveniences are:

  There should be more beans (date-picker, sorted tables, ...)
  More integration with the host OS (file extension integration, etc.)
  Better UI designers (now we have Eclipse and NetBeans, but even those should be improved)
  An easy way to use GridBagLayout (or a new layout)

  
  And many others more.

  I know that some of my complaints are now being solved or already solved, but 5 years ago (whe I strated developing Swing desktop apps), it was really hard, and much more hasd to be done.
  

  Posted by: peyrona on April 01, 2005 at 07:10 AM

• I can't speak for direct experience, since I've always developed rich clients and standalone applications, but my colleagues that have been developing with me swear that writing web application is quite a lot easier... no remoting, no problems with detached objects (we are using Hibernate), no need to create a swing model around every bean or bean list, no confusing events but only gets/posts.

  I'm feeling confortable with the above "problems", and I think that I would not be happy with the web "expressiveness" limitations, yet I understand that working in a more constrained environment keeps thing simpler if you can accept the limitations...

  Posted by: aaime on April 01, 2005 at 07:15 AM

• Over at www.wordmap.com we've been shipping a large Swing based app for the past five years, using web start whenever possible. It's an approach that's worked relatively well for us but we do regularly get asked for both a web-interface only and standalone .exe installations.

  There does genuinely seem to be a reluctance to install the runtime, and we'll often run into problems on client sites.

  Often times its the fact you need admin rights to install it that becomes problematic, along with its continued inability to be wrapped up into an automatic roll-out process: ref: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4898752 (secure desktops are a pain!).

  Web start itself can be a little clunky, aside from its scary somewhat lack-lustre dialogues having to set it up on each client to navigate the customers various proxies and firewalls often causes some headaches.

  Our typical roll-out consists of adding an Oracle box somewhere in the organisation, onto which I'll put an Apache server to distribute the web start files from. This often works out to be more acceptable than integrating into existing hardware & web containers. The user-installation uses the javascript checks for the presence of web start, when missing prompting the user to goto the relevant "get java" (java.com) automatic page. Which is a bit hit & miss, both as to whether it'll work for the client or not, but also on which jre version they'll end up with. It's horribly difficult to walk a user through downloading and installing a given jre version from the main java.sun.com site, just too many steps and options.. I'll often have to send their administrator a copy of the jre to distribute.

  Somtimes they'll just click on the wrong button when the XP SP2 pops upt o block the java runtime, sometimes they'll download the JNLP rather than running it (esp on mozilla).. Users will often complain that web start is all a bit odd.. adminstrators can at least be taught to love it when the app needs updating.

  And whatever happend to Java-Update?

  I'll often run into organisations that use a company-wide shared desktop image, which initially (just add Java) sounds ideal but experience has taught me Its always a show stopper. First of all because of the ingrained reluctance to modify and roll-out a new image but moreso because this image will already contain an older version of Java the customer already has dependence on. JDK 1.3 seems quite common, but we we're talking to a big potential client a few months ago frozen at 1.2.

  Finally as a developer of Swing apps I always have a problem getting over the 1 JVM per application problem. It makes it rather pointless to develop small-swing applications - when you've got a 30mb+ JVM process shadowing you there's no such thing. Hopefully the MVM can find a home on the client-side and be fully integrated with web start in the not-too-distant future.

  Corollary to this is the basic control I have over memory usage and limits (guesstimate at deliverly time and the JVM is often overly greedy, rarely freeing much back). No easy control over Process priorities (esp on Windows) how many times have you seen your favorite Java IDE at 100% CPU? Java apps make for poor desktop team players.

  Just some basic observations, maybe Sun should try eating more of their own dog-food :)
  

  Posted by: osbald on April 01, 2005 at 07:21 AM

• The component and appearance issues mentioned can all be worked around. Granted you shouldn't have to but there are solutions. However, I'll agree that deployment and jvm footprint are issues 1 and 2. If you want to be 100% certain you have the right version of Java to run your app with, you ship your app with a bundled version of Java. This increases the app's download size. It looks like this is what Limewire is doing for instance. If you don't ship a JVM it is a crap shoot. Most application developers don't want to worry about the JVM issue.
  Application size is an issue as well. Hypothetically, lets assume a large number of apps start being written in Java. I haven't verified the number but lets go with the 25m mentioned above. That means that 10 apps would take up 250 megs just at start.

  Posted by: scottdelap on April 01, 2005 at 07:24 AM

• We also bundle a JRE with our Swing apps. We wrote our own native executable to start thing off similiar to the Marner Java Launcher.

  This biggest frustration has been with Applets. Unless you develop for version 1.1 the odds are good that your user won

  Posted by: raytucson on April 01, 2005 at 07:39 AM

• Pelase see my comments at
  http://weblogs.java.net/blog/flozano/archive/2005/04/how_to_make_jav.html. I add a reason to the ones you cited: Lack of code sharing among apps
  

  Posted by: flozano on April 01, 2005 at 08:05 AM

• One word why: SWT

  Posted by: phlogistic on April 01, 2005 at 08:53 AM

• We ship a JRE with our Swing application (a data acquisition/analysis program). We do this in order to ease installation issues for the end-users and also to keep up the impression that this is just another Windows application. Using NSIS and JSmooth to integrate with the Start menu. So far, haven't had any comments or complaints about this setup.

  It would be nice to be able to ship a slimmed-down JRE since we install it in our own sub-directory, but the last time I looked you had to ship most of the JRE (with some exceptions).

  Posted by: gpayne on April 01, 2005 at 09:12 AM

• Boy, did you just hit one of my hot buttons.

  
  "We ship a Swing app on a CD with a bundled JRE. Webstart and bundling are the only two reasonable deployment mechanisms available from a QA standpoint."

  
  I totally agree with this. I am a contractor. Right now I am working for a company that ships a large Swing application (OpenWells from Landmark Graphics/Halliburton). The application works well, with the shipped JRE.

  
  Personally, I have problems with the whole implementation of JRE's on Windows. Those stupid java.exe and javaw.exe "stubs" that sit in the \Windows\system32 directory. The way they check the registry... The way the "last JRE installed wins"... It's a nightmare.

  
  Every time I use a Java application that DOES NOT install a JRE, I just know it's going to break if/when I install a new JRE. And sometimes it breaks in mysterious ways... like just the uninstaller breaks. For instance... I installed Together Developer as a trial. Subsequently I installed JDK/JRE 5.0. When I attempted to install Together Developer, the uninstaller broke.

  
  And I am a developer. I know how to fix all these things. But I absolutely REFUSE to inflict these sorts of problems on my users.
  

  Posted by: javalori on April 01, 2005 at 10:02 AM

• tools, tools, tools, and oh did I mention? tools.

  Even though I haven't touched it in years, I can still develop a windows app with MFC and visual studio faster and better than in Swing. Even the code looks nicer (because all the layout is in the RC file). And all the basic work gets done for me with a wizard!! (and VisualStudio v.5 doesn't need a gig of RAM)

  
  As an added bonus the app is a very small exe, fits on a disk and has no extra dependencies. Write once and install anywhere (on any windows box).

  
  And the best thing is that with C++/Delphi nobody says: ahh.. you wrote it in Java right? Nobody even knows or cares to know what I wrote it in.

  
  JDNC looks promising but doesn't seem like a high priority for sun..
  

  Posted by: dog on April 01, 2005 at 10:19 AM

• Windows look and feel doesn't look or feel like Windows. I like metal, personally, but I can't expect users to adapt to the new look and feel, and even for me, some components like the file chooser are just too different and/or ugly.
  Lack of smoothed fonts make everything look like crap.
  The API is large, all of its obsolete old baggage from AWT and old Image production/consumption has left a legacy of unwieldy complexity. Someone new to Swing could spend a couple of weeks just realizing that 40% of the API has been replaced by something new and better.
  

  Posted by: erickson on April 01, 2005 at 12:21 PM

• Put simply swing doesn't meet the requirements of a client application. If it did, you would see more swing applications and this blog would not have generated so much feedback. I have the same problems as the rest of you. Swing is difficult to program well, it is not consistent across JRE versions, and you can't use it to make an application look and behave like a native windows application. Swing will never be used widely for client applications until it look and behaves like a native application. As a consultant I've actually had a client that would not allow client Java applications in their organization for this reason.
  More importantly can any on give me a compelling reason to choose Swing instead of a native Windows application other than the ability to run on multiple platforms.

  Posted by: hammer on April 01, 2005 at 12:43 PM

• We have shipped several Swing based apps, with either a bundled JRE or via JLNP, both options have worked well. Even though we develop with Java for cross platform, in reality we only deploy GUI apps on Windows, but we do test on multi platform, one of our developers is running Linux another is running on a Mac OS X. This is as opposed to our web apps that are running on both Linux and Windows.
  In terms of performance, we built a Swing based realtime scanning program that scanned skins to determine there size and thickness profile and provide the operator with information for sorting the skin, this was written four years ago and is still being used. The client is extremely happy with the solution.

  For look and feel I have used a couple of options in the last year (using JRE 1.4.2), WinLAF and JGoodies Looks, both of which provide a nice look.

  Posted by: bcrammond on April 01, 2005 at 12:45 PM

• 1. Because Swing is very clunky to use. Netbeans is an okay Java Swing app. We use the Sun ONE Messenger instant messaging client at work and every time it is restored from the system tray, it doesn't redraw correctly. It fixes itself when you try to resize it though. However, that's a Sun app. They 'should' know how to use Swing.
  2. What have they done with Swing in the last few years? Not very much. Their dollars are in Java mobile computing and other profitable projects. They have tried doing things with the Java desktop which I have honestly not tried, but most of the widgets I've heard are just that, widgets.
  I remember hearing about Lotus Office Suite rewritten in Java. It was scrapped. It doesn't exist.
  Sun just didn't execute with Swing. They saw potential in the server apps and concentrated their dollars in the server space.
  A decent UI has to be snappy and familiar. These two things Swing is not - currently.
  Also, JTables are still a nightmare. Is the data updated when you press enter or when you lose focus or what? Can you add a listener to detect changes and do it manually? In some situations yes, but you are never quite sure.
  Rant goes on.
  It is just not yet ready for prime time in my opinion. That's after several years of development. We're up to Java 2, or 5, or 1.5 or something like that.
  I love Java and have done quite a bit of Swing programming. However, to me it is reminiscient of J2EE - complete yet cryptic, only Swing is not so complete.

  Posted by: jhanna on April 01, 2005 at 03:18 PM

• I ship two Swing apps, but I develop them using the Swank toolkit that allows one to script the GUI with a Tk-like interface. This eliminates a lot of the pain of Swing (of course I paid the price already by writing the Swank toolkit in the first place).

  Posted by: bruce_johnson on April 01, 2005 at 03:36 PM

• I do not create SWING apps since free java runtimes only poorly support swing and its in my mind to "overdesigned". Its a bad example to what OO coding can lead.

  When using LwVCL (www.lwvcl.com) I can use AWT, SWT or even .NET as a backend withought the need to worry about open or closed source runtimes.
  It also has only 200kB (compared to Swings 4mb quite lightweight) and loads much faster compared to Swing. And it is java-1.1 compatible which (must) have still priority for me :-(

  lg Clemens
  

  Posted by: linuxhippy on April 01, 2005 at 11:20 PM

• I do ship Swing Apps (available for download at truemirror.de) and think that Swing has some clear design advantages like pluggable look and feel, a modified MVC architecture and a simplified interface for multithreading.

  On the other hand, although I use NetBeans 4.0 and JDK 1.5.02 it is very hard and time consuming to develop a sleek looking UI for my applications. Some of the issues coming to my mind are:

  Poor standard look&feels: The native Java look and feel has a sex-appeal comparable to Windows 3.1 - it should be dumped! If you are looking for a cross-platform l&f the choice left with the JDK is GTKLookAndFeel, but unfortunately it is not deployed with a JRE on Windows! After having a look at the JFileChooser in this l&f I suppose I understand the reason for this decision. There are a number of other issues (primarily about background color) with this l&f feel too, so it is currently not an option. I hope these issues will be fixed by Sun because GTK is one of the most widely adopted open source UI toolkits today. After all, I use SkinLF in order to use GTK skins, but I am not happy about this solution either because it does not support GTK+. There is one issue left with GTK anyway: You couldn't put your skin into a JAR and access it as a resource because the GTK theme file syntax does not support this - Sun may think about an syntax extension to solve this issue.
  Broken JFileChooser: Has Sun ever tested JFileChooser on Windows? In 1.5 it does not support UNCs anymore (this worked in 1.4.2) and it does not paint properly with some custom l&f like SkinLF. Moreover, has anybody ever tried to write a custom FilesystemView? This is almost mission impossibe because the base FileSystemView class uses way too many "instanceof" clauses instead of simply relying on overriding. So I had a very hard time making my app browsing ZIP and JAR files like directories, but I finally made it.
  Missing standard keystroke semantics: Everybody expects a dialog to be closed when you press ESC. With a JDialog you have to write custom code to do this and this is not even easy to understand (why register keystrokes on JRootPane rather than JContentPane?) - ouch. setDefaultButton() simply does not work sometimes, too.
  Poor mnemonic support: Although there are at least two ways to specify a mnemonic, they are simply to complex. Microsoft has a far simpler method by using the ampersand before the mnemonic character in the text string. This is both easy to remember, saves a lot of typing and simplifies internationalisation.
  Missing support for HTML 4.01 in JEditorPane: It's 2005 now. I also completely miss HTML support in TitledBorder - I would like to use <em> or other text in parts of the title sometimes.

  
  Some of the issues I could solve myself writing custom classes which extend the base Swing classes, but I could not overcome tthe feeling that I am constantly reinventing the wheel. Does Sun know and care that they are about to loose the desktop to .NET? If they are wondering about the reasons then I think the current shape of Swing is part of the answer...

  Posted by: christianschlichtherle on April 02, 2005 at 03:16 AM

• 
  Hi Joshua, we are desperately trying to ship a swing app via Java Web
  Start, and it's been a nightmare.

  First, the user probably does not have a JRE installed (or not an
  up-to-date enough JRE.) So offer them to download one from
  java.sun.com. Oops, broken link, Sun moved the JRE again.

  OK so they finally found the JRE, and had an administrator come and
  install it for them. But now we have to somehow convince the user to
  click "Yes" on that big scary "It is highly recommended not to install
  and run this code" dialog. (I do understand the logic in the warning
  and not running such code automatically, but still, this is a hurdle.)

  
  Then there is the syntax of the JNLP file. This is pretty much a
  guessing game, even with the documentation and hours of googling. Try
  writing one that specifies a particular J2SE right down to the "_xy"
  release... it's possible, but do you know how? The "href" attribute
  must be specified if you want to request a specific JRE version, such
  as "1.4.2_07". But if you want 1.5 (and no "_01" specifier) you have
  to be sure to LEAVE OUT the href, otherwise it doesn't work! This is
  but one example of JNLP quirkiness.

  At some point, we got frustrated and ended up using a 3rd party tool
  to ship a JRE with our web start apps pre-installed. Yet another
  nightmare. The location of the JWS deployment dir (currently
  C:\Documents and Settings\username\Application Data\Sun\Java\Deployment)
  seems to change from release to release. How do you deal with
  machines that have several JREs installed? And the files installed in
  DMweb-start\DMlib ? You have "jar" files that are actually
  certificate files, timestamp files, or property files or
  god-knows-what, but they're not jars!

  
  OK, so now I've got a custom Windows binary installer for my Java
  Web Start app (do you see the irony in that?) Now I want to do some
  basic audio or video on the desktop. Hmm... gotta use JMF which was
  last updated in let's see, 1999 or so. Wanna use a modern input
  device like an XP TabletOS pen stylus? Good luck.

  
  This is a real mess for even experienced developers to wade through.
  I truly love the Java programming environment, especially on the
  server. But the trouble of getting a JWS/Swing app deployed has made
  me consider whether I would have been better off using something like
  Flash on the client end.

  Please accept this response to your blog as some constructive
  criticism for Sun, and not just random bitching. I really hope that
  these problems can be straightened out some day.

  Posted by: armhold on April 02, 2005 at 06:20 AM

• We would really love to deploy Swing Apps but it is too complicated to deploy. Not only is the JRE too large and requires too much effort to install on the part of our clients, but startup is still too slow and multimedia support is lacking. We are using Flash for our games, webapps for our back-office admin tools and Java on the game engine. I don

  Posted by: ajavasmith on April 02, 2005 at 07:56 AM

• Hey Josh

  This whole discussion reminds me a lot of problems deploying client/server solutions back in the early 90s. We had the same issues of the deployment runtime--in our case, PowerBuilder, but VB and others had the same problems. Then there were issues about external dependencies with libraries we needed for the app.

  It seems like WebStart is a first try at solving some of this, but it's pretty clear to everybody that it doesn't work as well as advertised. When I compare with "installing" a Flash program, or even Thinlets--those just work.

  The other thing is that Swing seems shy of the run-anywhere promise, and this is a problem for users. Slava Pestov, author of jEdit, blogged a couple of months ago that he was giving up on Swing (apart from jEdit), because of the numerous problems--he has special-case code to handle KB and other input quirks for different OSs, for example, and if you follow the jEdit lists there are regular issues with different Linux distros.

  I'm glad that you're now working with the Swing team, and that there has been more activity there the last year. I'm hoping the group can step forward with a good plan in the near term to put our fears at ease.

  Patrick

  Posted by: pdoubleya on April 02, 2005 at 11:02 AM

• We actually ship and deploy an Swing application using Java Webstart.

  But recently we encountered some troubles with the migration to JRE 1.5.0. Actually we only needed Java Webstart 1.5.0 because of a specific feature, but someone at sun decided to skip providing it as a standalone application. Sad but okay.

  Swing is okay with a high potential for being cool, but then things such as Christian Schlicht Herle pointed out. Or in our eyes the designer or developer of the Swing Text packages must hate everybody, who wants to extend it. We wanted to use it as a base for an WYSIWYG Editor, now we have written most of the stuff ourself, cause it is not useable. Not useable by design, but by implementation. You can't overwrite methods, that you want to and need to.

  Posted by: fitheach on April 03, 2005 at 01:30 AM

• I've noticed in a number of similar threads that there are often posts by people working with Swing who have solved some of the problems that people are complaining about.

  For example, the lack of databound components. One poster complained about the lack of them, the next poster complained that he had write a number of them himself. It seems like the answer to the first poster's problem is to use the components that the second poster talked about.

  Most of us work on projects either within corporations or as part of consulting engagements where we frequently deal with these issues. I'd like to suggest that as we address some of these shortcomings, we contribute the results back to the community through either JDNC, or OpenJNLP so that we're not always continually faced with a lack of Swing-based solutions.

  Expecting Sun to solve all of these problems is misplaced optimism. Sun's only going to address the problems that either have a vocal, engaged community (through the JCP) or where it sees a clear profit motive.

  One clear and simple solution that Sun can offer, is to provide the community with a sample desktop app that's easily extensible and provides enough blueprint information that the average web-app developer could figure out how to create their own well-behaved desktop app. The existing Web Start apps might make a good starting point -- assuming Sun released the source code.

  Posted by: phidias on April 03, 2005 at 10:49 AM

• We have deployed a swing/webstart based rich-client business application and I have to say that it was a complete nightmare. When development started over 3 years ago with j2se 1.3 we had no
  option but to build our own custom framework because j2se 1.3 and swing did not support even the basic stuff out of the box.
  Windows LAF in j2se 1.3 was a joke. We quickly moved to JGoodies Windows LAF. No form based layout. Had to write our own. No widget databinding. Had to write our own.
  No class that encapsulates money - the heart of a business application. Ever used double or Double and dealt with the rounding issues? Had to create a custom class that used BigDecimal.
  No widget level validation and exception reporting mechanism. Had to write our own. No easy date calculator - ever tried using Calendar to find the number of days between two dates?
  Overriding default focus behaviour gave us nightmares with double cursors and unstable widgets. Overriding JTable's changeSelection() gave us even more nightmares.
  The other problem is that there is no standard rich-client application framework built on top of swing. We needed something that would help us to define screens, link and navigate between them. Or to do basic CRUD business stuff like searching using a criteria, navigating through the search results and editing data.
  I used to be a loyal swing supporter until this real world experience. We spent a way too much time just writing plumbing code, and basically fixing the short-comings of swing, instead of developing a business application. After all these years it's starting to depressingly look like swing will never be ready for prime time.To summarize, the reason why people don't ship swing applications is because it is just too damn hard. Period.
  

  Posted by: nileshpereira on April 03, 2005 at 12:33 PM

• I didn't take time to read all the comments so I'm sorry if I repeat something that has already been said.
  I must add that we bundle a complete Swing app (Hibernate, iText, lots of big jars) AND the JRE 5.0 within 12.3MB.
  We made that possible by stripping out the JRE to the smallest size possible, packing JARs with Pack200 and using NSIS installer with LZMA compression. The whole JRE is actually packed to around 6-7MB. Since more and more people have access to high-speed Internet, this is far from a big overhead. Even with a 56K connection, the overhead is about 25 minutes of download time (which is, well, acceptable).
  What is the most impressive is that, after the installation wizard, the whole thing weights a hefty 92MB (!)

  Posted by: krakerjaak on April 03, 2005 at 01:57 PM

• Hey Josh -

  Would you care to do a wrap-up of this and tell us what you might be planning to do about some of this stuff?

  Posted by: grlea on April 03, 2005 at 05:52 PM

• We just decided to use WinForms instead of Swing because we needed to embed a smart client within Outlook, and with Infragistics NetAdvantage Suite Schedule component, it was a breeze, we didn't spend time trying to change the appearance of the Swing schedule component. This is a component vendor that I think doesn't see much revenue from their Java components, since them appear to me to be stagnated, and pale when confronted with their WinForms cousins. Of course there is the Smart Client Developer Center with a good amount of resources as is usual with MSDN, the Smart Client Architecture and Design Guide to get guidance even if one is not an expert, and the Smart Client Offline Application Block to jumpstart quickly a thin client application. On the other hand, we have this and of course JGoodies. Sorry, but this time we chose the path with least resistance.

  Javier

  Posted by: javier on April 04, 2005 at 12:54 AM

• Hi Josh,

  I think the main thing that Sun needs to do in order to popularize Swing applications is to support a new Installer Tool in the next release of J2SE SDK.

  What I want is that when I create a Swing-based application using an IDE like Eclipse or NetBeans, I should be able to run a tool that creates a double-click installer for my application. This installer should have the following features:

  
  Install my swing application
  Have options of typical, full and custom installation
  Download and install a compatible JRE on the user's machine (if required)
  Create an unistaller
  Create shortcuts to my application in commonly used places like the Start Menu, the Desktop and the Quick Launch bar
  Allow the user to select a look and feel (or skin) during installation

  
  To summarize, my application installation and usage should be very similar to a native OS application. Once I have this sureity, I will start writing Swing based applications without the fear of deployment issues.

  Most of these facilities are in-built in the Java WebStart, but there is no tool that automates this entire process of creating an installer without the need for the developer to learn a lot of new stuff.

  Amit Batra
  Computer Scientist
  Adobe Systems India Private Limited

  Posted by: amit_batra on April 04, 2005 at 01:24 AM

• I have a second comment to add, triggered by a couple of things written here. People have (justifiably) complained about the install process, lack of powerful components (data binding, calendar, others) among other issues. Now, a reasonable interpretation of Sun's actions to date would be to say they expected to cover a certain amount of infrastructure tasks for Java, and have the free market supply extensions and extra features. After all, we can't expect Sun to do it all, and other companies, notably Microsoft, at one point were able to build a huge secondary market of "pluggable" components.

  So--outside of WebStart-specific issues--there are commercial GUI components, data binding APIs, and app frameworks. There are also commercial installers. There are some FOSS developments for these as well, in various stages of development. So if these are available, why are people complaining?

  One reason may be that these kits are too expensive for casual purchases, and developers don't always have the say in whether their bosses or clients will invest in them. People also might feel that Sun should be providing a wider range of features with the JDK as regards Swing applications.

  Still, I'm interested in this aspect of the question. People have good criticisms of WebStart, and I won't argue with those. But as for comments that Swing is too hard, has poor look and feel, lack of good components--it seems that for not too much money any team can have any component/framework/GUI-building suite out there. So, isn't that enough? And if not, why not?

  Patrick

  Posted by: pdoubleya on April 04, 2005 at 04:44 AM

• 
  it seems that for not too much money any team can have any component/framework/GUI-building suite out there. So, isn't that enough? And if not, why not?

  Are you serious? I know of only one decent one (JGoodies). I'm sorry, but there is no ecosystem of 3rd party swing components - and that's part of the problem. Look at the number of vendors and open source groups providing frameworks and tools on the server side. And compare that with this

  Posted by: nileshpereira on April 04, 2005 at 06:53 AM

• Having spent the last eighteen months developing a Swing based desktop application, for deployment across a handful of university departments, I've gain a small insight into the potential problems which are encountered.

  The first problem is that Swing is something new. Not to you or I, but to the end user. It isn't a Windows program (as they know it) and it isn't a web app. I had to spend a long time explaining how HTML, CSS and Javascript simply couldn't provide an interface rich enough (and reliable enough) to manipulate the kinds of data structures required by the project. The good news is, once everyone had agreed to use a desktop app, Java's WORA seemed to give it the edge of a straight forward native Windows implementation.

  The next problem is, as you correctly noted, is that Java applications cannot be just downloaded and run, like native apps. There needs to be a JRE - and a correct version too.

  There's no standard cross platform way to install Java programs. As my userbase was reasonably small for the initial release, I was able to ship it as a Zip file. But it became clear that something with a bit more power was needed. Perhaps it's time for the JRE to feature a dedicated installer tool? Not only would it be nice to be able to detect which JRE is installed, and automatically prompt an update, but also to detect what other packages are installed. It's a shame that ever desktop application has to come with its own copy of any supporting packages. If the installer could accept a list of required third-party Jar's (including locations) and download them as required into a shared pool - and if the JVM could automatically find these Jars (without having to trawl through every Jar in a crowded 'shared/' directory) even if filenames changed between versions (which would suggest some kind of abstract mapping between package name and its actual physical filename in our shared pool) then that would be ideal.

  Another problem I encountered on the PC was that other applications 'stole' the .JAR file type. Notable PowerArchiver on the PC, which upon installation assigns JAR files to itself, overriding the "java.exe -jar" of the Java installation. Double clicking the Jar did not run it - but instead brought up the archiver utility to edit the Jar. This can be a swine to fix, as it requires talking the user through reassigning the file types back to Java (which in turn requires talking them through finding their most current JRE). In the end I made an educated guess at a VB Script (aahhhh it burns it burns!!) to locate and reassign the file type back to Java. Of course, this causes problems when run on a machine with a virus checker.

  The final problem - more of a niggle really - was that AWT/Swing's ability to work with its enclosing desktop environment is patchy at best, and seems to have taken a low priority in development terms. For example, it was only with 1.4 that we finally got undecorated windows and the ability to place the window 'naturally' on the desktop.

  Posted by: javakiddy on April 04, 2005 at 07:01 AM

• Because the free software implementation of Swing is not finished yet.

  On the other hand, Java-GNOME and SWT work great with free software implementations, so that's what I recommend that people use. Java-GNOME in particular is very cool, and it's a bit unfortunate that Sun's not interested in it, despite basing JDS off GNOME.

  Oh well, more power to Mono. :)

  cheers,
  dalibor topic

  Posted by: robilad on April 04, 2005 at 07:36 AM

• Yeah,there Is some crucial feature missing in Swing ,and customer don't like Swing' App in Windows world. And more Important thing is about reuse,OS API reuse is the key reason.

  Posted by: isaacxu on April 04, 2005 at 08:43 AM

• I'm a big fan of Swing and in the last few years I've used it to single handedly write what many tell me is the best Swing desktop productivity application:

  http://reportmill.com
  http://reportmill.com/rm8/RMStudio8.jnlp (Java Web Start)

  The biggest problem with Swing is that it's hard to build UIs. Apple makes this easy with InterfaceBuilder and Microsoft makes it easy with VisualBasic and such. Swing's layout manager architecture is a bit too clever for its own good. For ReportMill, I felt comepelled to write my own GUI builder to overcome this problem:

  http://reportmill.com/ribs
  http://reportmill.com/ribs1/Ribs1.jnlp (Java Web Start)

  Sun needs to jump start Swing development by putting some good Java Web Start applications out there, with source, starting with a good, stand-alone GUI builder. They should also create a simple word processor, a simple page layout application and maybe a good mail client or web browser. People could use all of these as a basis for starting their own desktop applications. And something like this would be necessary to overcome the intertia of the old, but current perception that you can't write desktop applications in Swing.

  jeff
  214.513.1636

  Posted by: jeff_martin on April 04, 2005 at 11:28 AM

• Becuase it's has a warning message when you ship a signed WebStart application.
  Mobile Java is user friendly to deploy.
  Swing is not, it cost us money. I have several million users deployed:
  http://forums.java.net/jive/thread.jspa?threadID=315&tstart=15

  
  .V

  Posted by: friendvu on April 04, 2005 at 01:49 PM

• JRE is very big to ship with small applications. But it is not possible to rely on the currently installed JRE. It should be possible that only the required parts of the JRE to be installed and updated -preferably through web- when needed.
  

  Posted by: mnuhoglu on April 05, 2005 at 01:53 AM

• I am currentlry releasing a swing app (a small open source project done by myself). But I think that java app are always seen as "evil" from the desktop users. I think that there are two things that are more important than any other to be solved: First, multiple apps had to run in the same VM, share memory and so on. Second, JRE should be smaller, purged by a lot of stuff needed by a tipical "business" app and not needed by a typical desktop app. What is needed is a minimal JRE with an automatic retriavial of standard lib from sun site when needed.
  These things will be very cool :)
  

  Posted by: ildella on April 05, 2005 at 02:28 AM

• If I can summarize:
  JNLP-WebStart team at Sun has done nothing in 4 years to help you ship anything. They do not even understand a friendly message like: "Please install this application, the vendor is authethicated" as oppopsed to the current WebStart messge: "Please don't install". The current staff at Sun deployment, thinks taht they should prevent installs. 2 open source JNLP libraries fix this. Put somone from mobile java on the desktop deployment, and it will be fixed. It's becuase us the developers are too stupid to understand security, according to the officail line from Sun.
  Use JGoodies forms layout, not grid bag
  Use JGoodies looks for look and feel
  Use JDNC for data biding.
  Have peopel in charge of developer advocacy get Limewire, Lazarus (30 million desktops) convert to JNLP, the standard deployer to eliminate mutiple version of Java issue. (Right now, "best prctice" is that each application should include 18 meg JRE, so if you install 2, one of them can break.
  that fixes it. I think most belive that Sun will not fix it becuase they don't care; once "classpath", the open source "java" is out, there will be a lot of swing deployed. And no, I do not think Sun will comprehend. At JavaOne exeuctives promissed Java client side, but middle managment f-ed it up.

  .V

  Posted by: friendvu on April 05, 2005 at 04:53 AM

• I was C/C++ developer when i started a swing project in my spare time. I have chosen Java because I get more in much less time [my spare time!]. Doing it for three years now. Speed and LnF seems not to be the biggest issue of my users (crossword puzzle editor). They don't care if it is written in Java or not.
  The very first problem is start/installing the app. either with a startable jar-file or through an exe-installer. Sometimes a ZIP-programm is grabbing the *.jar extension and leaving the software unstartable.
  Most common questions of my users is: How do I start?
  I wish I could easily integrate my app in the installation process of the standard jre. Without creating another local JRE copy in the apps directory.

  The steps should be:
  1. Install JRE if needed.
  2. Install my swing app.
  

  Posted by: ptea on April 05, 2005 at 03:27 PM

• I do ship a Swing app. But there are complaints in a few areas. As others mentioned the abysmal performance of JFileChooser on Windows makes people think the application has deadlocked, and there are severe restrictions within JFileChooser, like broken context menus, no sorting, etc.. it basically only looks like a real Windows file dialog for the first two seconds... then it fails miserably. (The directories-only version also looks nothing like the windows directory browser.)

  Basic things like not being able to set the minimum size of a JFrame (still broken in Java 5 unless you use Metal LAF *and* turn off decorations).

  We are forced to distribute the JRE with the application, because the application is too fragile if we don't. There needs to be a better way to install JREs in a shared way so that they are somewhat protected from getting screwed up/upgraded by the user.

  Repainting issues. On some systems withe specific nVidia cards Java applications simply don't paint. Disabling use of DirectDraw is a workaround.

  Synth look and feel is very buggy and hard to use due to lack of documentation.

  Windows seems to aggressively page out any Java application that isn't in the foreground, so clicking back to the Java app's window results in a minute or so of paging to get it back in. I'm guessing this is likely caused by large heap usage from Java, and the fact that a garbage collection will walk the heap forcing it to get paged in all at once??

  Bug fixes from Sun take a very long time. In general Java releases have a lot of things wrong with them. Usually only one or two things actually matter to any single application, so we can get by... but the outstanding bugs in Java are astronomical.

  Better control of WebStart technology is needed. It should be possible to write a custom .exe launcher (so the process list shows the name of my app, not "java.exe") and use Webstart to ensure that the correct version of Java will be used with my app (so there only needs to be one copy of any specific JRE version on the system. Updating the code to the latest version available on the net must be optional and under program control. E.g. I want to be able to put up MY dialog that says a new version of my application is available and let the user choose to update later or stop showing such messages.

  Posted by: swpalmer on April 05, 2005 at 08:11 PM

• I ship a Swing app: http://www.loopholesoftware.com/
  and do Swing 8 hours a day on contract.

  * Swing pisses me off every time I use it.
  Latest abomination has been rolling my own sorting for JTable, like about 10,000 developers before me. It made me realize how poorly designed Swing really is (JTable, in particular, is a hack).

  * Swing Team's priorities are completely screwed up.
  Proof: JDK 1.5 offers a "skinnable look and feel" which nobody gives a damn about, yet omits JTable sorting.

  * Given Swing's head-start, and Sun support, the success of SWT is further proof that Swing is a disaster.

  * Swing's record of performance and reliability is just sad...

  Swing has earned every one of my nasty comments. Java 2.0 should start from scratch, with new ideas, and a new development team.

  Posted by: ashackleford on April 05, 2005 at 08:14 PM

• My organization ships a Open Source Java application set which includes some Swing apps (the jSyncManager). We target virtually every OS capable of running Java 1.4 or better, so unlike some of the posters here, we've run into some different issues, not all of which have to do with Swing.
  Indeed, packaging for all the different platforms our applications can run on is one big hurdle. We rely on a few standard extensions which have native components (ie: javax.comm, javax.usb), so we need to create seperate packages for each OS platform. It would be really nice if Java had some sort of built-in standard installer (other than just WebStart) which application developers could hook into and use. As it is right now, we're duplicating a lot of effort across different platforms trying to package the code in a manner that is easily installable on each platform. Mac OS X appears to be the only platform that makes it easy for us to do this. Installing Java applications so that users can use them is still a bit of a PITA.
  And that's not even considering whether or not the user has a suitable and working JRE on their systems. Windows users have a mish-mash of possible JRE's on their systems at varying versions. Linux distros virtually never have a decent JRE on them (due to licensing issues). The only major current OS's which tend to get this right are Solaris (duh) and Mac OS X (OS/2 also used to be pretty good, but is now generally irrelevant, although we do still have a few users of our software on that platform).
  Good OS integration is another problem. We don't want our users to think of our software as being written in a specific language when they run it -- it shouldn't advertise itself as being in a specific language by the way it looks, feels, or acts. Our UI is simple compared to a lot of other projects (due to the nature of our applications -- they don't require a complex UI). Desktop integration is virtually non existant. Intra-application drag and drop support across platforms is a joke (I once added some code to allow files to be dropped into a JList in addition to providing a button and a file chooser, but it only worked on Windows and nowhere else so it was removed). Attempting to interact with the users desktop in a cross platform manner is also non-existant. (I do understand the level of complexity in abstracting all the ways desktops have been developed, but it's still a hinderance that users notice). If we want to do any of this sort of stuff, we need to start relying on different platform-specific APIs, which complicates the build system and the requirements. If we're goinng to go to all that effort, why even use Java for the UI in the first place?
  The way the different classpaths interact is another problem I'm constantly bumping into. The fact that starting an application using the "-jar" parameter invalidates the CLASSPATH setting is a constant trip up (my latest run in with this is with javax.usb (aka JSR-0080) on Linux: the RPMs install the libraries into /opt/javax-usb/lib and a properties file into /opt/javax-usb/etc, and then set the CLASSPATH to point to them -- but as soon as a user runs "java -jar jsyncmanager.jar", both the libraries and the properties file can't be found for loading).
  Work needs to be done on the file choosers as well. I have yet to see a platform where the file chooser Swing provides matches the OS-specific file chooser (admitttedly, I don't do any development on Windows). This is yet again another reminder to the user that they're using something non-standard on their platform of choice.
  What Sun really needs to do is to take some well-known native applications, and try to replicate their UIs in Java using Swing. Discover during development where the bottlenecks are in trying to make those UIs look and feel the same on different platform, and then fix them. THEN sit end users in front of those Java applications, and see what they notice is different. Then go back and fix all of those issues.
  Complex Swing GUIs are still too memory hungry as well. Limewire, for example, on OS X10.3.8, requires 62MB of real memory at load time. The jSyncManager, which has a very simple GUI, takes 25MB of real memory upon load. Users are starting to get used to running multiple applications at once, but many of them don't have the RAM to do this with more than a few Java applications without going into serious swapping. Firefox on my system is using just shy of 58MB of real memory at the moment along with a number of plug-ins and extensions, and is quite a bit more complex than either of these applications.
  There is also the perceptions (often incorrect) of Java that I run into every day with end users: Java is bloated, Java is slow, Java is hard to configure, Java isn't free enough. It's hard to sell users on Java applications because of these perceptions -- many will simply dismiss Java out of hand. They may have experienced the nightmare of setting up their CLASSPATH, they may remember how long it took to download applets on their 19.2kbps modems using Java 1.0 years ago, or they may have had bad experiences with how badly some conforming Java applications run on Microsoft's old VM.
  Now I can sell an end user a Java application if they don't know it's a Java application. The speed issue is mostly a thing of the past (assuming the user has sufficient RAM and Java doesn't force them to go into swap). JARs and the Extensions directory(/ies) help diminish the CLASSPATH issue. But if the look and feel and lack of UI integration screams "Hey! This is a Java application!", they're going to let their prejudices concerning Java dictate whether or not they're going to use the software.
  I should probably wind down this long and rambling post before I think of some more reasons why we have trouble attracting users to our Swing client software. I'l just end off by saying that once Mac OS X 10.4 ships, I'm considering doing an OS X specific version of our GUI applications using Cocoa/Java, built atop our pure Java engine/API. Apple has done a lot of work to make Java applications look and function well on OS X to the point where it is possible to create a Java application that is indistinguishable by the novice user to a native application. It isn't 100% perfect (although today I was playing with Quaqua, which somewhat improves the Aqua L&F -- including supporting native file chooser dialogs -- woo hoo! :) ), but it's a sight better than what most other JRE implementors have done.
  Brad BARCLAY
  Lead Developer & Project Administrator,
  The jSyncManager Project
  

  Posted by: yaztromo on April 05, 2005 at 09:15 PM

• I'm going to add one thing if Sun is ever serious about "fixing" Swing: take a look at how GUIs are developed under Cocoa.
  Now that Swing object serialization appears to have been standardized in Java 1.5, Sun should work on making the way users develop Swing GUIs the same as how cocoa .nib files work: draw your GUI by manipulating the live objects, make the connections, and then serialize the whole thing to a file. The provide a mechanism for easily loading, deserializing, and making accessable the objects in those bundles. Create the tools to create and serialize the GUIs in this way. Stop using the current mechanism all Java IDEs currently use of trying to generate code for what you've designed.
  Personally, I hate GUI coding. It's dull, boring, and thankless work for something that should be easily automated. And yet I'm always stuck doing this by hand because all the IDE's I've used either generate wierd code, or code that you then have to go into and add your own code to to get it right (and flexible enough to make changes easily when needed), which then confuses or breaks the GUI builder tools. It's an unnecessary mess.
  The good news is that all the parts are in place to make this happen. Swing now has standardized serialization. We can serialize to XML. The JAR format could easily be reused (with a different extension) to store these files into logical bundles that are then loaded by the JVM and deserialized when needed.
  (As a side benefit, knowledgable end-users could easily make minor modifications to GUI applications to suit their needs without any programming knowledge. The other day I changed a Cocoa app I was using which had a useless joke-type button on it the author decided to add to be cute. It was useless to me, so I loaded its NIB into Interface Builder and set the button to be invisible so it didn't bother me anymore).
  I recently started learning Objective-C and Cocoa (I'm relatively new to the OS X platform), and coming from the Java world the way you design UIs is just a huge breath of fresh air. With it I can easily create advanced GUIs without any programming, without any fiddling with any generated source files, and without a compile step for the GUI elements. As mentioned before, my Java applications, the jSyncManager is fairly simple GUI wise, and yet still has roughly 30 - 40 GUI class files out of 207 total (in the main project tree -- this doesn't count the various add-on and plug-in source trees). This seems so unnecessary when our product isn't about the GUI, but about providing synchronization protocols and services for PalmOS devices.
  Sun should take a very close look at what Apple (and NeXT before them) have done with Interface Builder and serialized GUI elements in OpenStep and Cocoa, and should then create a similar system using Java and Swing. That would make GUI development significantly less burdensome on developers, and would remove 90% of all of the Swing GUI code floating around out there (and with it lots of design flaws, code that needs to be maintained, added compile time, etc.)
  At this point, if it had the cross-platform strength of Java, and built-in garbage collection, I'd be strongly tempted to drop Java completely and move to Objective-C and Cocoa (or GNUStep). As it is, Java is a fantastic language with a really good selection of APIs -- but a really painful GUI environment to work in.
  Brad BARCLAY
  Lead Developer & Project Administrator,
  The jSyncManager Project.

  Posted by: yaztromo on April 05, 2005 at 09:42 PM

• Ask yourself this question: "Why did Azureus, a popular BitTorrent client use SWT instead of Swing?" You will fool a user into thinking java is native with SWT. You won't with Swing. Ever.

  Posted by: bgardella on April 05, 2005 at 09:49 PM

• 
  
  
  
  
  
  
  
  Your question is really a question about what is wrong with Swing for first class desktop applications.  Ok, as a long time Mac person who looks back fondly at MacApp (in its final form as a comprehensive solution to an application framework), I have lots of opinions (as all of us Mac people do), but here goes....
  1.) Java is not a general purpose programming language. GC is fine, except when you NEED to turn it off.  Poor support of native types (unsigned int??  Who would ever need that?).  JNI is an abomination.  The support for native code should be almost transparent.  Wait, I forgot, Java is as fast as C/C++.  That is why my Java IDE has been frozen for the last two minutes.
  2.) Swing lacks basic support for fundamental features that one might expect in a application framework.  It was designed for applets.
  3.) No true MVC architecture.  Controllers, anyone?
  4.) Layout Managers are for web pages.  Anyone who espouses the use of GridBagLayout should be banned from writing desktop applications.
  5.) Cross-platform Look-and-Feel is the worst idea ever.  99% of Windows apps look like Windows, but I have this one Java Web Start App that has an Open File Dialog that looks to be designed by a fifth grader.  Cool!  I am sure that training my 10,000 employees about the difference between UIs will cost nothing.
  
  6.) Never let a Server company that was too dumb to buy Apple develop anything for the desktop or consumer.  If they had, we would end up with the JavaPod that could hold 5 songs and cost 3K.
   OK, that was uncalled for and I am getting a little cynical.
  
  
  
  SUNW Market Cap:
  13.58B
  
  APPL Market Cap: 34.23B
  We need great desktop applications.  Java could be great.  Swing needs to be completely rewritten.  Does anyone at Sun care?
  
  

  Posted by: tomcondon on April 05, 2005 at 09:59 PM

• We have been developping a large Swing / Java 2D application for years before thick clients got in fashion, assuming that Java and Swing performance would progress along time. And they did. But did they progress enough?

  We still bang on several issues (in addition to what others reported already):

  Speed of GUI development: It depends on a good bidirectional visual editor and we have not found any since the days of Visual Cafe, Java Workshop and even Eclipse. How does Visual Basic succeed to do it good, straight and simple at the same time?
  Very frustrating to develop via copy / paste without good fast prototyping.
  Memory footprint: on a tabbed panel with 8 tabs and inner standard components (buttons, labels, comboboxes, checkboxes) each one built with its own GridBagLayout, our profiler (JProbe) detected a huge char array of some 10 MBytes generated when the panel is loaded and garbaged collected when it is closed. It also impacts on speed of course.
  Start up time. Converting our app with Excelsion Jet AOT really impacts its start up time and first access to each new loaded class. Could there be a way to indicate to the JVM that classes that inherit from Swing must be loaded even before they are invoked.
  Tuning for garbage collection seems to me a mess and something internal that I should not be concerned of. Very interesting the caching schemes and the first/second generation stuff, but it should be mostly transparent. Anyway, the XX options change from JDK version to the next one.

  We chose Java for the "write once run everywhere" and we persist. But the look and feel on Unix is not nice.

  Jean-Pierre Stroweis
  

  Posted by: stroweis on April 05, 2005 at 10:16 PM

• I can tell you one reason I bet is happening, a lot of developers don't know or are afraid to blog about their company's products written in Java. Possibly out of fear of losing their job, or maybe they are not allowed to indicate the technology they use. You have heard, even hear in some of the replies, that many companies loathe the use of Java for products. It's so sad that they feel this way, and it's more sad to think some pretty amazing companies actually hire or have working for them morons that can't get beyond their own lack of knowledge about the latest Java to see what it can do. But with all the stories about blogging and ended up being fired for saying something you shouldn't have, I wouldn't be surprised if a lot of developers simply don't say anything yet they may indeed have amazing java products.

  Also, I will say some things we have discovered using various things. For example, we need to edit a JTree node and "select" the text within the node. When you create a new tree node, or rename an existing one, getting at the underlying JTextField is a PITA! This is something that is simply ridiculous to have to write so much code to be able to do. The short solution is to use your own tree cell editor, typecast the editingComponent (protected JTextField) selection when the component is returned.

  Another issue is while Swing can be a lot of fun to program with, there are small inconsistencies that can throw you off. For example, the JGoodies library is great, including JForms, and JLooks. But, because they hard-code the use of the Tahoma font within their components, I18N is pretty much toast. The fix is some sort of simple hack, but a hack none the less and then the formatting may get messed up. The point here is, and I am not slamming JGoodies at all..its great, but it is very easy for 3rd party libraries to "break" some expected behavior of say, a look and feel, not really acknowledge it, and leave those using it in a bind. This isn't a Swing specific issue per se, I'd almost say its a case of being too flexible. Also, a big issue with many starting developers is the learning curve and some of the complexities with things like tables, trees, lists, threads, event queue, and more. I know that its very capable and in my opinion I can't imagine anyone wanting to develop a potentiall cross platform app in anything but Java, be it client side or server side. That said, there is appeal to very good tools and ease of learning that MS seems to have the Java camp mostly beat in. Eclipse is closing the gap in the tools area, as is netbeans and intellij, but the learning curve to become very good with Swing is still prettty steep and usually requires the need to write pretty robust swing apps and have to learn it. I am still learning today (thankfully IMHO :)

  One thing that can help alleviate some of this is well written application frameworks in Swing that make the majority of application tasks painless. I am working on one such app (here comes a plug) available soon from www.platonos.org. My goal is to create a highly functional, pluggable Swing application framework that out of the box is usable. Much like how it is said that a developer can focus on the "logic" of an app and not worry about the common details, my goal is to provide a number of plugins with the framework, and even components to extend from or make use of, so that developers can hit the ground running and focus on plugin development for their application needs and less about the framework and basics of the application core. The plugin engine is nearing completion now, and I am incorporating the FlexDock docking framework along with some open-source components to build a Swing application framework that will be very similar to the Eclipse RCP and Spring Rich Client.

  Any who, please feel free to check out the framework (it is in an early stage now, but we have some pretty kewl plans for some of the plugins we are working on). We are really hoping to help fuel the push for Swing application development by providing developers with not only a pretty robust framework to start from, but one that is well tested.

  Posted by: buckman1 on April 05, 2005 at 10:46 PM

• Over the past several years, I have created and worked on Swing apps for scientific and engineering applications. But it's increasingly more difficult to justify using Java for this purpose. Major reasons include:

  (1) Integration with C/C++ is extremely clumsy by any means. I use JNI, but it is often nightmarish to try to debug problems that occur on the C side. Stepping between Java and C debuggers is difficult and usually ineffective.

  (2) The JDK MUST be shipped with the application. Too many things break between JDK versions to risk relying on what the customer has at his site.

  (3) Swing is still incredibly slow.

  (4) Swing GUI's still look very bad. I spend an incredible amounts of time trying to improve borders, spacing of elements, etc., with little real results.

  (5) I don't want to ship a bunch of jar files and the JDK to the customer. I want to ship an executable. A. Single. Executable. Program. Period. Why should I or the customer want or need anything else?

  (6) Memory footprint is massive compared to equivalent native applications.

  If Sun cannot address these points (and I'm sorry to say I don't believe they will), I am going to have to transition to a C-based alternative like Qt. I will miss the fun of programming in Java, but at the end of the day, I have to produce the best cross-platform program in the least amount of time. Java and Swing don't allow me to do that anymore.
  

  Posted by: danblanks on April 05, 2005 at 11:05 PM

• You asked for an honest opinion. Here's mine. I don't intend to be negative or overly critical but this is my experience using Swing in the fields.
  Simply put I now run away from Swing because my users don't care whether I used Java or something else to develop the app. And Swing forces them to care.
  You must realize that users are not using Java apps only. They have a mixture of apps on their machine and anything that is not a team player (such a Java/Swing app) is not welcomed.
  I'm a consultant/contractor and I have developed a few Swing applications for my customers. While the customers are generally happy with the design, the functionality and even the UI analysis (screen design and the flow between screens), 90% of the support calls I handle for those apps are because it's Swing. Users don't understand why it's not Windows or MacOS. I always have to invent workaround or whatever.
  It costs me so much to support a Swing app that it does not make good business sense to use Swing.
  Let's face it. A Swing application does not look, feel or behave anywhere close to a native application. The controls look very different, the color schemes don't match, the controls don't behave like native control, and on it goes. The differences may jump to your face the first time you launch the app (they will on Windows) but the user will notice as soon as he clicks anywhere.
  The only platform where Swing looks somewhat like a native app is MacOS X and even on MacOS, Swing will only fool a user for 5 minutes or so.
  I wish Sun would fix AWT. I have zero complains with Swing-based apps. With a few custom controls, because it blows Swing away. Always has.
  As far as I can tell, AWT is only missing a few options: the ability to set Alt keys for menu entries on Windows (in fact, this is the only serious issue with AWT as all the other issues can be addressed through custom controls), a native tab control, a native tree control, a native message/prompt box and a native table control. With those 5 small fixes (#1 is the most important one) which should not take a lot of engineering, AWT would address 99.9% of my UI needs.
  I can think of bonuses (e.g. more flexible list control, usable popup menus, etc.) but it's just icing on the cake. A more flexible list control would be an added bonus.
  I used to complement AWT with custom controls. Increasingly I use SWT.
  --ben

  Posted by: bmarchal on April 06, 2005 at 12:56 AM

• Dan,

  I guess I don't understand why you were using Swing in the first place then. It has gotten a LOT better over the past few years. I agree, JNI sucks. It should have a better way to interface with native platforms. Unless you are living under a rock, most users we have worked with the past year or more have JDK 1.4.2 installed. While a minor issue, every app we have written works on all flavors of 1.4.2_x. Without it, the only time a JDK shipped is bad is if you have to download the application. What Sun should do is provide a native wrapper and installer for each *major* platform, primarily windows, linux (gtk and other flavors), OSX and solaris. It should be a native app, like they do javac, java and so forth, so that you can easily provide a native wrapper to execute an application, even distribute it with a built-in JVM as part of the wrapper. That would be beneficial.

  Swing is FAR from slow these days. Not trying to slam, but are you sure you know what you are doing? The only thing slow that I see is startup times. Once running, on my 1Ghz laptop I don't see any major difference between a native app and Swing apps with the occasional hiccup of the GC running. If this is slow, then I am missing something. Entry level PC's even a year ago were closer to the 2Ghz range, so I doubt too many people who can afford to buy software are running very slow machines. Yes, there are some, but not nearly as many. Of the hundreds of clients I have seen us our stuff, not one is running slow machines. It's too darn cheap to upgrade/update to a new machine these days.

  As for the GUI's looking bad, sorry, dont buy it. I've seen some VERY slick GUI's done in Java, including our own application. It looks great and works smoothly. There are also L&F's that you can get for free or purchase that mimic windows more so. JDK 1.5 does a pretty good job there already, but even with 1.3 and 1.4 you can find some very good L&F's. Font's are the biggest problem with Java and 1.5 doesn't address it well enough, hopefully 1.6 will.

  If you want to ship an executable, get a wrapper. It's not hard. You can wrap your .jars and all that into a single executable file for different platforms. Even so, what's the big deal? The only reason not to ship jars and such is if your clients are concerned that you are using java, hence you want to hide the use of java. If so, switch languages. Java is great to program in, but has some downfalls. So what, every language I know of has these same scenarios. The benefits of java's superior language, ease of programming, threads, i/o, networking, larger library and more free/open source libraries than any other language make it all worth it! Footprint is not all that bad. With 1.4.2 it's about 13MB starting up, and depending on the app, goes to 20MB to 100's of MB's. Eclipse eats up over 200MB on my system. So does IntelliJ (ok, about 100MB). MS Word eats up a good amount too, so does Outlook and others. Whats the prob? Memory is cheap, most computers today ship with 512MB if not more. What I would be concerned with is how well you are writing your code to utilize resources in a good manner.

  At the end of the day, regardless of some of the short comings, Java is light years ahead of any other alternative out there for cross platform GUI apps, even other apps like services and J2EE as well. What I dont get is your last line, about how you can't do it any more with Swing? WHAT? Swing has gotten a TON better, so if you were able to do it before, but not now, I'd say your skills took a backseat to your complaints.

  
  bmarchai,

  How does Swing force them to care? How is Java not a team player? How do they end up knowing its Swing and not Windows or Mac OS native? Why do they care once they find out? What is it about the word Java (or Swing) that scares them? Are you absolutely sure its not the application you wrote instead of Swing? I can't tell you how many applications I have come across where the developers claim Swing/Java is dog slow, etc, etc.. I go in, fix a few things and it works 100 times better. Then they get all pissed cause I made them look stupid. I am not saying you are one of them, but I have seen and have (still do) worked with complex Java Swing apps that are very robust and tons of features and they work smooth. All the time. The only exception is the GC kicking in, and that isn't too often. Usually, calling System.gc() two times in a row gets it going more times than not during the app run and not waiting until its out of memory. Even so, its not that often and I generally write my java apps, Swing or otherwise, to make good use of resources, free them up (null refs, reuse lists, use static final constants, etc) to avoid a number of the issues that I have found plagueing the so called "java/swing slow" applications. If it costs you so much, why do you keep using it?

  Swing apps look and feel pretty darn close to every OS they run on. But I always ask, why do you want the same app running on two or three different OSs to look like native apps. Now you have to deal with WHAT OS it's running on, why the button over here ("Where.. oh crap, on Mac... let me transfer you to my Mac support person") isn't working, etc. Having the SAME GUI across platforms for your app is a better solution if you want to support it less. You claim you support it so much... stop trying to use the native L&F and find an alternative that "skins" your app, giving it it's own look. What's that? Users wont know how to use it cause it isn't "native"? Come on.. only if they are so stupid they have to ask how to turn the computer on. I have seen and used many L&F's, and with the exception of the Napkin L&F, there isn't one that doesn't perform VERY similar to all the others. I'd rather have a slick solid GUI that looks and runs the same on all platforms than three different L&F's, one for each platform. Talk about support headaches.

  SWT isn't half bad, and I will agree that it would be great to see a new Swing API. It just wont happen without a major rework of the entire GUI system. Frankly, I think an open-source javax. alternative is in order, but what is there works pretty darn good. I'd really like to see a lot more hardware support such as hardware accelleration, taskbar, systray, dock types of integration and control, and other aspects. Still, the generaly way Swing works is pretty darn good.

  Posted by: buckman1 on April 06, 2005 at 01:28 AM

• We are developing a comercial SIP client in Java / swing.
  I think it looks and work very good.
  We done it in record time and has all the features a native SIp phone and more.

  The phone is deplyed to hundred of users and no complains about java or swing. It is just 2mb in size and all the current users know they have to download the jre. In our installation we check if there is an installed JRE we can use, if not we provide the user a link to download the jre.

  We are doing also MFC. Both teams complain, the MFC team and the Swing team.

  
  

  Posted by: incarose on April 06, 2005 at 01:45 AM

• In my previous Compay we developed a First Class Swing Based (Remote Control and Configure) Browser Application for two of the Tektronix Test and Measurment Products.
  This works inside the Intranet, it can also work from internet, provided user have JRE 1.4 or above.

  
  We didnt faced any major problems related to LookAndFeel.

  
  Some of the developers in the team were new to Java so learning SWING API took lot more time than expected.

  
  I wish SWING API is bit more easy to use. I belive, for GUI applications, an XML or Scriptable UI makes huge advantage in rapid prototyping and quick GUI development .

  
  BTW:: And majority of applications at Tektronix Oscilloscope products front ENDs are developed completely in JAVA and SWING (which also includes a powerful Ploting and graph tools)

  Kishore.

  Posted by: kishoresjava on April 06, 2005 at 02:39 AM

• [quote]
  I have a work folder with about 900 or so files. When I navigate to this folder using the Swing file chooser it takes nearly half a minute to open. With the native file chooser this takes approx. 2 seconds. (BTW I am using a 3.4GHz P4 with 1Gig RAM, Win XP Pro SP2 with jdk1.5.0_02)
  [/quote]
  I repeated this test on:

  Mandrake Linux 10.1
  AMD Athlon64 3400+
  RAM 1GB
  JDK 1.5.0_03

  
  The script to create 1000 files is:

  =>
  #!/bin/sh

  cd ../test

  again=1
  while let "again

  
  Next I fired up the standard JFileChooser.
  The time to load the 1000 files was too short to notice, far less than 0.01 second.

  This is the code that does the magic:

  =>
  JFileChooser fileChooser = new JFileChooser(lastFolderName);
  fileChooser.showOpenDialog(MainFrame.getInstance());
  File selectedFile = fileChooser.getSelectedFile();
  =>

  
  Not exactly rocket science.

  Each and everytime I check some remark about Swing it seems I get a diferent result from the author.
  There are so many myths about Swing that I would like to rate it as folklore. I am working now for 18 months on several Swing projects and still have not encountered any of the horror stories you read about Swing so often.
  Am I unusually talented avoiding booby traps ? Very unlikely as I blew up the operating system of a Unisys mainframe computer the first day of my contract.
  No, it has to be something else.
  I have tested myself many negative comments made about Swing and none of them passed the reality check.
  Swing is hard to learn though, at least when you compare it to VB.
  Gosling compares Swing with the cockpit of a Boeing 747 and that is exactly the feeling that you get when you look at Swing the first time.
  However after a while you find that you use only a few of all the bells and whistles and you learn as you go. Do not try to learn Swing from a book alone.
  When we compare Swing with VB, than Swing is indeed a Boeing and VB is a 4 seater one engine rotor airplane.
  They have different purposes.
  It is simply not fair to expect the same level of knowledge from Swing as from VB.
  You can do so much more with Swing.

  I feel the core of the "problems" with Swing is the expectations of the developer.
  If you expect to just jump in and write some code, forget about it !
  Maybe there are some wizards around that just hop in and write some nice Swing desktop application.
  I personally have not seen them yet.
  

  Posted by: johnzoet on April 06, 2005 at 03:21 AM

• Correction:
  Some lines dropped from the test script above due to
  #!/bin/sh

  cd ../test

  again=1
  while let "again

  Posted by: johnzoet on April 06, 2005 at 03:42 AM

• The script looked good in the preview, but still does not come out right.
  If someone wants the script to replicate the test, drop me a note at:
  john_zoetebier_AT_transparent.co.nz.

  Posted by: johnzoet on April 06, 2005 at 03:45 AM

• The reason why I dont use swing is because WinForms provide an all around better solution for desktop applications running on Windows machines. The fact is that .NET is more optimized to run on the desktop than java, thus, .NET applications tend to be far more robust and faster.

  
  .NET has a superior look and feel
  Swing layout managers just plain suck
  For it to be older than .NET it is far less mature

  
  To be frank, I dont want a layout manager telling me or suggesting to me how to layout my components because I know best. It seems that Swing was ill conceived. Another thing worth mentioning is that it would be a big help if there were a tool comparable to Visual Studio .NET 2003. After using the beta Visual Studio .NET 2005 this does not look good for java in general with the advancements introduced. Also, the major selling point for java is that I can run it on windows, mac, unix, and linux. Guess what? I can do that as well with .NET now thanks to Ximian

  Posted by: ahives on April 06, 2005 at 03:49 AM

• The reason why I dont use swing is because WinForms provide an all around better solution for desktop applications running on Windows machines. The fact is that .NET is more optimized to run on the desktop than java, thus, .NET applications tend to be far more robust and faster.

  .NET has a superior look and feel
  Swing layout managers just plain suck
  For it to be older than .NET it is far less mature

  To be frank, I dont want a layout manager telling me or suggesting to me how to layout my components because I know best. It seems that Swing was ill conceived. Another thing worth mentioning is that it would be a big help if there were a tool comparable to Visual Studio .NET 2003. After using the beta Visual Studio .NET 2005 this does not look good for java in general with the advancements introduced. Also, the major selling point for java is that I can run it on windows, mac, unix, and linux. Guess what? I can do that as well with .NET now thanks to Ximian's (now Novell) mono, which I might add is superior to java even in its current state.

  Java is a great platform and I will continue to use it but not by choice. The thing is, Java, in general, is far too cluttery. Question? Why do I need five different APIs that do the same thing. For instance, why is there JDOM, JAXP, DOM4J, SAX, AND JAXB? In .NET I at least know that there is consistency. There is System.Xml to manipulate XML data. I know all the before mentioned APIs provide different featueres, but, it would be more ideal to combine their strengths and rape it up into one API.

  Another thing is deployment. Why would I want to create an application that needs the command line to run? I know what you are thinking. There are ways to create an executable. Yeah, but its not native to the JDK. I never have to worry about this in C/C++/.NET.

  Also, Swing's presentation of data is just ugly. I read in this blog about how good the latest java is. You are absolutely right. It is good. Compared to the previous releases of Java. I hope that you are not comparing java to .NET.

  I think the gentleman that wrote the ReportMill application is missing something in his synopsis. That is time. How much time does it take to roll your own layout manager. I am quite sure that this could have been done in .NET with the same functionality but much faster. Time is money.

  When your business logic is already complex, why add complexity to the building the UI when these things should be implicit. In fact the only advantage java has over .NET is that it has been out longer. Technologically speaking there is no advantage. Although, you can do every and anything in java that you can do in .NET. However, you can do it more efficiently, faster, and better in .NET than in Java.

  It is beyond me that J2SE 5.0 is less mature than .NET 1.0 beta. Also, I think there should be a compilation option. Deployment should not be as difficult as application development. I think before .NET it was easy to praise Java for being innovative and a great new technology because the alternative was C++. But now since there is a technology to compare Java to we can now see that its deficiencies are widespread and glaring.

  Posted by: ahives on April 06, 2005 at 03:50 AM

• I use jvider to develop Swing interface wich is about the same as using Visual Basic. Then I use Eclipse to code the package necessary for the application inside a JFrame and then jar everything in a signed Applet.

  The first time the application is downloaded by a customer there will be a check of the jre version. After that the customer will always have an up-to-date application.

  Swing is too slow? Thank God threads are there to isolate long background processings.

  Ciao

  Posted by: plasante on April 06, 2005 at 03:54 AM

• One of the best experiences I have had as a user of a swing application is MagicDraw which is a UML tool. I've been using MagicDraw for the last three years and I consider it the best value in a UML tool on the market. The UI is very clean, the tool is very stable and I have used it on Win32, OS X, as well as several distrributions of linux. I think MagicDraw demonstrates that swing can be used to create robust UIs.

  Posted by: mark_reynolds on April 06, 2005 at 04:26 AM

• Hi!

  I do use Swing, I like it and I shiped one very big and some smaller
  Swing apps. Nevertheless I think the biggest barriers for getting into
  it are infrastructure problems like:

  Deployment (Webstart, EXE-Wrappers and Native Installers like
  NSIS are a solution but it takes some effort to get into them and to
  find out which one the best for what)
  GUI-Building (All LayoutManagers that ship with Java are really
  poor and not intuitive to use, JGoodies Forms is yet a very good
  solution for me that you can use without a GUI building tool very
  well). You have to really study Sun's LayoutManagers deeply before you
  can use them with our without a 3rd party tool like Netbeans that
  supports you with laying out a GUI.

  Look&Feel (It's hard to build a professional looking
  application with Sun's L&Fs, again JGoodies Looks is a very nice
  and professional looking solution).
  Printing: That's the most annoying thing for me. To print out
  some simple data on single or multi pages is still a big deal in java
  and very poorly documented. Printing out a table came in JDK 1.5 and
  the results are - kindly said - unprofessional. There are a lot of open
  source frameworks out there that provide reporting in various formats
  and generating PDF files, but yet there is no support in JDK 1.5 to
  just print a PDF file.

  My resumé is: It's hard to get into it, you have to look at 3rd
  party tools so solve some of the most common problems, but once you're
  into it and know your neigbourhood, it is great fun and easy to deploy
  professional looking and ergonomic applications that look and feel the
  same on most of the OSs that support java.

  Cheers, Thomas

  Posted by: tbolz on April 06, 2005 at 04:27 AM

• I Do ship a Swing app - http://www.guiffy.com

  Guiffy works with any JRE from 1.1.8 (with Swing 1.1) to 1.5.0_01.

  Two things restrict the acceptance of our application:
  1) Startup performance
  2) FileChooser performance and features
  

  Posted by: britcher on April 06, 2005 at 07:55 AM

• Josh

  we have based the core product of our company on Swing: a server-side proxy library to the complete set of Swing widgets that enables using Swing in a server-side Web architecture.
  We do this by applying the Half-Object + Protocol design pattern (see http://javadesktop.org/articles/canoo/index.html) to the individual Swing widget classes.

  Our experience when developing and marketing this library (called UltraLightClient) were as follows:
  - the early versions of Swing were very buggy and needed a LOT of workarounds/fixing
  - Swing has improved a LOT over the years. Today we are quite pleased with it, and believe me, we really use every bit of it
  - Swing still suffers from a bad reputation: we see that when we talk to potential customers, who sometimes need to be convinced

  Posted by: elisabeth_maier on April 06, 2005 at 08:51 AM

• Howdy. I've been using Java to write GUIs since Java was first released to the public. Been using Swing since the start.

  
  Agree that deployment is a huge issue. Agree also that making things look "native" to users is a big issue. Many users get upset when something doesn't look or work the same as it always has.
  And how many times must someone implement his own sorting and datasource binding with JTable???

  
  But I think one of the problems is Swing apps usually look quite boring. There are a lot of windows apps that don't look at all like the usual, where something really cool and different has been done...media players, for instance. My complaint is that this kind of thing is very difficult to do with Swing. Non-rectangular JWindows and JFrames? Cool-looking non-rectangular widgets?

  
  I would like to see painting tools that help me easily make something different and fun. Typcially, I'd like to paint my own background. To start with separate paint() into paintBackground(), paintForground(), and paintBorder(), with I can override only one and keep the default for the rest. (ditto with the LAF's.) Then provide new implementations of java.awt.Shape and java.awt.Paint that do really cool paint effects so programmers don't have to do it over and over and over again.

  
  Another problem: Arrogance on the part of the Swing Team. So many times I have reported bugs or suggested enhancements by opening records in bugtraq, only to be immediately dismissed. Doesn't give one warm fuzzies about the future of the product.
  

  Posted by: woofgrrrr on April 06, 2005 at 09:27 AM

• Swing is somewhat of an outcast. It does not adopt to the native platform and is way to large to load quickly.
  I develop web based applications and within a browser I can't count on swing being there and it starts even slower.
  Sun has a horrible legacy of inadequately supporting installation needs of Java. As already mentioned by others,
  the JRE is quite large
  locations for Applet-JRE installers changed on me (can you believe it?) forcing me to update all my clients installations
  Applets can't be run in browsers off CDs (needs always an installation of the browser first - very bad for multi media give aways) - you can blame that on the browser manufacturers, but where is the effort from Sun to help open source projects like Firefox to fix this. Or where is a decent documentation for this?
  Not much support for open source in general. For example Firefox requests the password authentication for a page, for the applet a second time. It should be shared with the password manager. Sure, this is Firefox's issue, but does this matter, if you want Java to be used on the desktop? Can it be easier than bringing the resources to bear to fix a problem in an open source project?

  Sorry many of these are general Java issues and not only Swing, but they show how little attention is payed to installation issues. Just my five cents worth.

  K<o>

  Watch out Sun, Google shows the developer world the way to just use JavaScript to replace Applets.

  Posted by: kajkandler on April 06, 2005 at 09:32 AM

• I have a work folder with about 900 or so files. When I navigate to this folder using the Swing file chooser it takes nearly half a minute to open. With the native file chooser this takes approx. 2 seconds. (BTW I am using a 3.4GHz P4 with 1Gig RAM, Win XP Pro SP2 with jdk1.5.0_02)
  Posted by: johnzoet: I repeated this test on:

  Mandrake Linux 10.1
  AMD Athlon64 3400+
  RAM 1GB
  JDK 1.5.0_03

  Each and everytime I check some remark about Swing it seems I get a diferent result from the author.
  Regularly we get complaints about how long it takes to open the file chooser in Swing running on Windows. That it is better on Linux is not the point; I get a better result running the same code on OS X than on Windows. But the customers for the software run Windows, and whether you can ship a swing app to the customer is the point of the discussion.
  I have tested myself many negative comments made about Swing and none of them passed the reality check.
  You have not presented any evidence of this.

  Application engineers create software for users, and the users expect that the software does not have these spurious delays, which are easily repeatable on some Windows systems. This has nothing to do with the quality of the application engineer's code (usually as simple as your example), but is a flaw in the underlying libraries.

  If you think mandating that you have to install a different OS to run swing based software is the solution for desktop deployment I'd suggest it might be you who fails the reality check.

  
  Pete

  Posted by: pete_kirkham on April 06, 2005 at 10:06 AM

• We ship our product as a Swing Applet. Yes, as an applet. I think Swing is pretty matured to be used for developing Enterprise Level software. I have following points,

  - Regarding the performance, one can get a maximum performance out of a Swing application if it is designed properly by giving proper attention to the ‘All Mighty’ GUI Thread. But I still agree with other people about some of the Swing components not functioning as desired, like JToolBar dragging.

  - Need of JavaPlugin for Swing Applets is another issue which makes it difficult to convince people for using Swing in an Applet.

  - Sun should really focus more on making Swing lightweight and easy to deploy.

  Apart from that I just love using Swing in my App,,,
  

  Posted by: rahulgs on April 06, 2005 at 11:19 AM

• Swing needs:

  Robust HTML+CSS rendering

  XUL, or equivalent

  XForms, or equivalent

  Decent layout managers

  I've written more at: http://www.davidflanagan.com/blog/2005_04.html#000054

  Posted by: davidflanagan on April 06, 2005 at 11:21 AM

• I needed a HTML browser bean for swing that would allow very accurate rendering of html pages. I tried some of the 3rd party offerings, but they were not seamless enough and would not display multimedia elements. I was going to try the JDIC browser component, but it does not support OSX.

  Without a good html renderer and support for WORA on Windows, Linux, and OSX, I had to turn to SWT. I wanted to use Swing, but had to go with SWT because of one aspect of the project.

  PD

  Posted by: powerdroid on April 06, 2005 at 11:32 AM

• This is for Joshua,

  Josh, in reply to your post, you see MANY different aspects of why Swing is not used, and for most of the replies that DO use Swing, you are given a number of issues that would make it MUCH more viable to use for application development. Today, in silicon valley (where I live) there are actually quite a few jobs available for *knowledgeable* Swing developers, which in my opinion is the best its ever been for Swing development. But, I am hearing a loud and clear cry for a number of fixes/advancements for Swing to really take hold.

  It's pretty obvious that even thought OSX is considered a superior OS than Windows, and linux is storming the world in many small companies and 3rd world nations, Windows is by and far the dominant OS still in use today, and most likely will continue to be so. One of the loudest messages is that users are not happy with the "plain" looking Swing apps that most of them appear to be. I agree with this to a point. I have seen a large number of Swing apps, including in the Swing Connection screen shots that are very plain and pretty much older looking. Some of the screen shots, to be fair, are taken in older versions of Windows. Still, it seems very clear to me that if you have any influence within the Swing team at Sun, you would raise the flag to get Swing to be about as close to native look and feel (and performance) as possible. Personally, I dont see a major cludge with it on Windows, but I have read all too often there is a lot lacking even with JDK 1.5 and WinXP.

  Second is the lack of adoption by those that hear the word Java and run. My co workers, friends on blogs, etc have chatted on several occassions as to why Sun does not promote Swing more. Java, for that matter is not highly promoted. Today we have kids growing up using computers on a regular basis in school and at home, and more adults are computer savvy than ever before. So why we don't see commercials, ads and so forth promoting Java, Swing, and more, I am at a loss to. We all know that IBM's OS/2 was far better than Windows but lost to marketing. Many a company have had superior products only to lose to a less capable product due to marketing. Why is Sun not marketing Java more? I think Sun needs to begin a campaign of educating companies as much as possible to the benefits of Java, and Swing within their organization. There needs to be a sort of "brain washing" going on to get more and more to acclamate to the use of Java and that its a good thing. What about it?

  Lastly, I stated before and I agree with this whole heartedly, installation and the size of the JRE is a major drawback. Sun should have been providing some sort of native wrapper/installer for Java a while back. I suppose now that the Java Desktop and Swing are starting to be used more, it would be a good time for Sun to really consider ramping up engineering support for Swing to make it not only faster and more native like, but to provide better solutions to be able to install a java swing application. More so, I really think it would be great to trim the JRE greatly. Maybe for Java 6.0 you can removed any deprecated methods/classes from 1.3.x and earlier? I still see stuff from 1.2 that is in there. I thought the deprecation was going to truly remove stuff one version later. Stuff like the huge libraries for CORBA... why are they built in? Frankly, I am in the camp that I would rather have a segmented JRE. Make one big dev one, and allow "pieces" of it to be deployed. J2EE is done in this fashion. Break out the JRE into smaller pieces. If you don't need Swing, why do I have to deploy the JRE with Swing classes on the J2EE server? If I don't need XML, why do I have to download a 13MB JRE that includes a lot of XML classes? I am guessing this will never happen, but if it did, I think it would greatly ease the burden of web start downloads, getting java apps installed and downloaded and more.

  For what its worth, I love Swing! I prefer it over any other type of development, but I do agree that the majority of developers who dislike it or compare it to .net and say its no where near as good have not taken the time to learn the inners of Swing. And that there is the drawback. There are a lot of lazy developers (sorry, maybe I should say those interested in only getting a product out the door and not caring much about how the dev/tools they use truly work). These are the developers that prefer drag/drop VB that bloats the crap out of code, but gets the product done faster. I am not one of those, but many are out there and as you can see, slam Java and Swing more specifically because they expect to simply drag/drop and run. Apparently they haven't done any googling to find plugins for Eclipse, NetBeans and other IDE's that do allow you to do this quite easily.

  Posted by: buckman1 on April 06, 2005 at 12:21 PM

• 
  I love how the only reason that developers find swing hard must be because
  we're idiots. Or how it's so easy to fix swings problems by googling for
  and using (non-existant) third party tools and libraries. I think the
  only people who like swing are people who don't actually develop real world
  applications in swing. Because if they did, they would know better.

  
  Since no actual solutions have been presented to our problems, for my
  next project I'm going to recommend we use SWT. After all, it can't
  possibly be worse than swing. And if I anyway have to write my own framework
  that does layout, data bindinding, focus management, validation, threading,
  etc, what advantage really does swing offer over SWT? Atleast with SWT I won't
  have LAF or performance/memory issues. I've already noticed the open
  source community moving to SWT in droves. I believe it won't be long
  before business application devlopers move too. Swing is rapidly losing
  mindshare to SWT and no-one at Sun besides Joshua seems to even care.
  

  Posted by: nileshpereira on April 06, 2005 at 12:53 PM

• I think one of the major problems is that Sun never appreciated the value of Java as simply a cross-platform language instead insisting it was a cross-platform environment (a vision extremely difficult to realize with Microsoft's desktop dominance).

  When Java was first released, developers jumped on it in droves. It's advantages as a programming language-its avoidance of pointer problems, its ability to create GUI's for multiple platforms, and the ease with which multi-threaded and network applications could be created help Java endear itself to a generation of frustrated C/C++ developers.

  
  The final step however, 'getting the application to the desktop' was the one piece, the critical piece of the puzzle that was missing. Sun insisted users would have the JVM which would execute java byte code. This of course led to performance issues but as a whole it didn't seem to be a bad idea to try to isolate the programs from the systems they were running on.

  
  This idea probably would have worked fine, if Sun had had the support of Microsoft (the company that controlled an overwhelming percentage of the desktops that Sun was targeting) to distribute the JRE. Once that was no longer possible, the responsibility of seeing to it that the end user had the correct version (or any version) of the monolithic Java runtime environment fell to the developers and end-users themselves; and this was a burden they simply couldn't or wouldn't bear. (Even WebStart isn't really an answer here-how many applications do you suppose would be written for Windows if users had to download every single library that makes up the windows API with every application?)

  
  From a desktop perspective, as years go bye, it is getting increasingly difficult to maintain any level of enthusiasm for a technology promoted by a company that gives you the impression that it somehow missed the boat; especially as the large technical lead that Java once boasted of has diminished or been entirely wiped away by alternate technologies and languages (such as C#). (And please understand, this comes from a long time Java fan).

  
  If Java allowed users to create self-contained, easily redistributable native programs, you would probably see a much larger number of desktop applications written with it. The problem here of course isn't technical; its policy. Sun won't allow you to compile Java libraries down and redistribute them. (This isn't as much of an issue with Java libraries where alternative clean room versions are available, but with Swing where I have yet to see a solid alternative, it is an unbeatable obstacle).

  
  There are of course other problems facing desktop Swing applications-but this in my mind is chief. I'd love to distribute desktop applications that use Swing but I don't need the performance issues that using Swing entails, and I certainly don't need the complication of end-users needing to download or obtain the JRE. While I don't personally believe that SWT is nearly as well developed as Swing, due to its architecture and its more developer-friendly licensing, it gives me some hope that Java can finally crack the desktop. The same can't be said for Swing or anything else I've seen from Sun in a long time.

  Posted by: coryn1 on April 06, 2005 at 01:34 PM

• Firstly, it's really pathetic having a commenting system that requires users to log in. The whole point of comments is that they should be accessible by infreqent visitors, not people who are members of a particular group; that is, unless you don't like outside comments.

  Secondly, it's not so much Swing that's bad, but the management of the JVM/JRE on Windows platforms. There were 20 versions of Java 1.2, another 20 versions of Java 1.3 and 20 versions of 1.4 released. (Yeah, they stopped being numbered all the way up after the 1.1.8 debacle; 1.4.2 sounds much better than 1.4.20)

  As a result, people with slow (or metered) connections don't have the ability to download the latest and greatest each time. That causes problems over a wide variety of clients since you never quite know where bugs are, or when they've been fixed by the VM itself.

  Lastly, Swing has no frameworks for even the simplest kind of UI actions, like wizards, drag-and-drop or preferences that are likely to be part of most applications. It's why more and more people are using the Eclipse Rich Client Platform to build apps; not because it's the best (although it happens to be at the moment), but because it's a great set of frameworks for building an application instead of a set of widgets.

  Swing might be more useful with a declarative style of user interface construction (e.g. XUL or similar) but is most likely to be benefited by providing UI frameworks for building applications instead of a JFrame with a Menu Bar. Once the frameworks are there, people will write apps.

  Mac OS X has the most advanced set of frameworks for building applications; as a result, Mac OS X apps are almost always higher quality than a Java (or Windows) counterpart; because there's less that the developer can do wrong. There's also more Mac OS X GUI applications than there are Java GUI applciations, despite Mac OS X being newer (that is, discounting the NeXT heritage) -- simply because of the quality of frameworks that allow applications to be put together in very little time.

  More on this subject at When Java just doesn't Swing on my my blog.

  Alex.

  Posted by: whyfuckingregistertocomment on April 06, 2005 at 04:31 PM

• It's getting pretty late, and I'm getting pretty bleary-eyed. I hope this is coherent.

  I've been programming graphics and GUI apps since 1983, so I can compare Swing (and Java-2D) with lots of other GUI and graphics frameworks that I've used in the past. Swing followed the typical pattern for new technology, in that it was useless for a few years, but got much better as time passed. I think alot of the complaints I am reading were valid a few years ago, but not anymore. While the Swing API is awfully big and complex, and can be hard to learn, it also means that it is very flexible. I can do things with Swing that I was never able to do with other GUI frameworks. Still, I find that alot of the functionality you take for granted in a Windows application simply doesn't exist in Swing.

  For the past two years, I've been working at home on a Swing application that I hope to sell someday. It's very text-intensive, and makes extensive use of the JTextPane and DefaultStyledDocument classes. I need to use Java because I make heavy use of introspection and regex. I looked at SWT for GUI development, but it's text components were not extensible enough, so I stuck with Swing. I'd hoped to be selling it by now, but it's taking much longer than I thought, mostly because a few Swing problems are taking me forever to get around.

  A general problem is that there are very few books that explain Swing in depth. The only one I have that does a good job is Kim Topley's Core Swing Advanced Programming, but it was released during the transition between 1.1 and 1.2, so it's pretty dated. The other books only go to a superficial level. I wish someone (Sun?) would fund an updated version of Topley''s book. I spend an inordinate amount of time writing little experimental programs in order to learn how parts of Swing work. At times when debugging, I've tried reading the Swing source code to see how it works, but often it calls native code. I've actually resorted to using Java decompilers on the native code, but it's really a pain. Why can't Sun release the native C code?

  As mentioned by others, the JFileChooser is worse than useless. There is no built in way to select files and use a right-mouse button popup menu to cut, copy and paste them using the clipboard. Dragging and dropping files was also a hassle to program. There is a long-outstanding bug in JFileChooser where copying a file to the clipboard actually results in a cut. There is no easy way to delete to the trash can. (I know Java programmers may not care about this, but users sure do!) What I ended up doing was learning how to do Windows shell programming, and then using JNI to call though to some C code that called Windows shell code. I spent months trying to overcome these, and other unmentioned problems with JFileChooser. If I was using a Windows GUI toolkit, I probably would have spent less than a day on it. Unfortunately, my hopes for developing a program that ran on Linux went down the drain by doing this, but running on Windows is more important, and I can't ship a program that doesn't implement basic File Chooser functionality.

  I also found it difficult to develop decent print and print preview functionality. The articles and books that talked about it were too simplistic. I also couldn't find any third-party software that did the job. Trying to get a StyledDocument with mixed text and graphics to show up correctly in a print preview window is a real pain. I finally came up with something, but again, it took months.

  I haven't worked at Sun since 1997, but I don't think things have changed much. Their typical users were highly-technical and captive. Their customers might be annoyed at having to download a JVM to run an application, but they'll do it because they probably have no choice. Microsoft, even though you might have complaints about bloated and insecure code, knows that it's users are less sophisticated than Sun's, and makes an extra effort to polish it's desktop applications to make them easy to install and use. Sun just doesn't have this type of end-user focused culture, and I think it's one of the reason's Sun is having such a hard time understanding what it takes to capture a portion of the desktop market.

  Posted by: ssinai on April 07, 2005 at 12:51 AM

• I worked on an internal tool, so we never intended to ship it anywhere, but I used Swing for five years on that project. It was a very successful project, and the users were very happy with it, and adding new features goes quickly. But we only needed to support Windows which made it easier.

  As much as I like Swing, I have some problem with it. Many of its more powerful features are a pain to use. But some of the problems mentioned above have easy fixes, and it's useful to look at why they're not used For example:

  
  A lot of people here claimed they couldn't get smooth text. If they want smooth text, they can simply override paintComponent() somewhere near the base of the component tree, like this:

  JPanel vPanel = new JPanel( ) {
  protected void paintComponent(Graphics gg) {
  if (gg instanceof Graphics2D) {
  Graphics2D g2 = (Graphics2D)gg;
  Map rMap = new HashMap();
  Object key = RenderingHints.KEY_ANTIALIASING;
  Object value = RenderingHints.VALUE_ANTIALIAS_ON;
  rMap.put(key, value);
  g2.addRenderingHints(rMap);
  }
  super.paintComponent(gg);
  }
  };

  It's a simple piece of code, but boy, it sure could use a better API. Well, let's just say it could use an API. No wonder nobody uses it. Oh, BTW, it's a bit flakey. It sometimes doesn't work if it's too close to the base of the component tree. I'm not sure why yet. I run into this kind of flakeyness a lot with Swing.

  
  Swing's reputation for being slow may be partly because NetBeans is so slow. I never had performance problems with our app, but I had big ones with the NetBeans IDE. If Swing runs slowly, it may be your framework.

  
  Then there are the features that are hard (or tedious) to use:

  
  Swing's components are powerful, but I often had to wrap them in other classes to make them usable. If you finding yourself writing a lot of boilerplate code to handle memory mnemonics, you need a new approach. My menu code let me specify all menu attributes (text, accelerator, shortcut, etc) in a single line in a properties file. This made things much easier, (and adaptable to I18N), but I shouldn't have to write it myself. I also wrote wrappers for borders, and I still need one for Calendars. (My border wrapper has useful static methods like addBorder(JComponent cmp, Border bdr) which puts a new border outside the existing one.)

  
  The GridBagLayout is ridiculous! It's a pain to use, and there are some things that just don't work. (Ever tried to add a JTable to a GridBagLayout? That's fun.) The BoxLayout would be a welcome replacement, but even that is a pain in the buns. Setting the HorizontalAlignment property to one will sometimes put the component at the right edge, other times at the left edge, depending on the other components! (That's a powerful feature, but it shouldn't be mandatory.)

  
  Many components are very frustrating to work with. I had to subclass JTextField, JTextArea, JTable and a few others to work around their bugs. (Most were eventually fixed.) The JTable's entry problem can be fixed in a subclass. Then you need to make sure you never instantiate JTable directly.

  
  I would never even dream about shipping a Swing app without bundling it with the correct version of the JDK. I can say with near certainty that (a) older versions won't work, and (b) upcoming major releases also won't work, because something will break with the next release. Even Swing's new focus managing in JDK 1.4 broke a crucial component of mine. JDK 1.5 broke menu mnemonics.

  Posted by: miguelm on April 07, 2005 at 01:01 AM

• Here's one (strange) advantage of Swing.

  
  The pluggable L&Fs may be a problem for some, but they also helped me fix a problem. Our editors needed to read disabled text, and Windows disabled labels are illegible. I subclassed an L&F class to implement disabled text that was readable.

  But many of the problems with Swing are design problems, most of which could eventually be fixed if only the Swing team took them seriously. A lot of them can't be fixed by subclassing components, but with small changes, they would be easy to work around. For example:

  
  The menus had bugs that I couldn't work around, because I didn't have access to the MenuManager. I'm not sure what the point of an encapsulated menu manager is if we can't replace it with our own subclass. That would have let me work around a lot of JMenu bugs. My request to give us access to the memory manager fell on deaf ears.

  
  Swing has terrible support for custom input devices. My laptop's scroll pad (next to the track pad) is functionally identical to a mouse's (supported) scroll wheel, but the Swing Team is in a quandary about how to support it. Native applications never have this problem. It could be solved internally by mapping all input OS events to their java equivalents, but the Swing Team doesn't seem to know what many of those events are. In my book, this flaw rules it out for shippable applications.

  
  Splash Screens are useless if we have to wait for the entire VM to load before we see them. I'd like to see an option to specify a splash screen on the command line. A splash screen needs to appear with absolutely no delay.

  
  Could you please document the undo classes?

  Posted by: miguelm on April 07, 2005 at 01:07 AM

• There is a whole set of problems that seem to exist because the Swing Team is unfamiliar with the needs of GUI developers. In some cases, they don't seem to know how today's GUIs actually work. For example:

  
  A Windows-only bug with the Minimize button was "fixed" by somebody who apparently never uses Windows. He assumed that the Maximize button was its inverse, and ended up swapping a Minimize bug for a Maximize bug. This isn't his fault. It's management's fault for assigning him the task.

  
  Modal Dialogs! Does the Swing team understand that we sometimes need them to be modal to the application and other times to a single Window? Wake up, guys! This bug has been around for five years. (I know, it's committed to be fixed in Tiger. Finally!) I can understand getting this wrong in version 1.0, but please! This can often be a deal breaker about shipping a Swing application.

  
  The JTable's entry bug is amazingly bad. It's a simple fix, but the swing team is content to treat this as "working according to Spec." Have they never considered the possibility that the spec is wrong? Or incomplete? I always say never give the customers what they ask for. Give them what they actually want. (I can tell you stories about this.)

  
  Most GUI platforms allow some kind of keyboard manipulation of visual controls. Swing's support for these is usually pretty bad. Mnemonics finally got fixed in JDK 1.3, but they're broken again. Moving through a list by typing the text that you're looking for did eventually get some support. I had to kick and scream for two years before they finally decided that, yes, two menu items should be allowed to share the same mnemonic. (Have they never used mnemonics? Or are they taking the spec too literally?) Please give decisions like these to developers who actually use and understand the features.

  
  The JTable still has a mode where the blinking caret is turned off while the user type is typing. How are users supposed to know where their text will go? I'm told that this is a "visual cue" about who owns the focus, but it's a ridiculous cue.

  Frankly, I would consider going back to the AWT if it would support the CVM architecture. Lightweight components have their place, but so do heavyweight components. That must be why so many people are migrating to SWT. I've never used it because I can't stand Eclipse, (It writes code for me, in files that I don't even have open!) but I can see why it's popular.

  If I were to ship a Swing application, I would give it its own, custom UI, which would look the same on all platforms (and look better than Metal), to let users know that this isn't a traditional Windows application, so it won't quite act like one, and also to reduce the number of platform-specific bugs.
  

  Posted by: miguelm on April 07, 2005 at 01:42 AM

• Even JDNC looks like it could do with some work on aesthetics. The datepicker and table column headers in particular.

  Posted by: jdolphin on April 07, 2005 at 04:48 AM

• We have shipped a client-server application, the client being a Swing GUI deployed through web start, using RMI for client-server interaction. My thoughts are that Swing does have it's faults, but it is quite competent nonetheless. It takes a little while to get into, but then it's not really that hard and now I'm able to create a GUI fairly quickly without using any kind of GUI designer.
  As opposed to many complaints I hear, I actually find the LayoutManagers to be very handy. You don't have to use them if you don't want the benefits, but if you do, I found it does a lot of work for you that you would have to do yourself in for example VB. It simply saved time for me, even though I needed to familiarize myself with them.
  This application has been deployed at many companies (some of which are very large multinationals) already and we've had absolutely no difficulties with having java installed. It was simply no issue at all. The users were generally very pleased with the fact that they could use the client GUI on any work PC. We only used the standard native look&feel, which was basically fine for our needs, even on windows it provided a L&F almost indistinguishable for the average user from a native windows app.

  Even given the fact that Swing does have its faults (as discussed by others here), look at it this way:
  Compare swing/rmi to a web interface. It didn't take me any longer to develop than a webapp, and the end result is a swing app which provides a much smoother, familiar and responsive user experience than you typical web application.

  Posted by: erikd on April 07, 2005 at 08:29 AM

• Nothing keeps me from shipping Swing apps, it's a technology that works, but it's not easy to do. One app I've shipped (EMC Control Center) a user would never know is Swing, got a 5 out of 5 for usability, and is again up for Storage App of the year Awards. I'm currently involved in internal financial applications which work very well too.

  The problem is how long does it take you to ship a Swing app? You need lots of developers and many just don't understand the intricacies of Swing needed to make a usable UI. It's too hard. What is needed is a strong framework on top of Swing and the tools to support it - either from Sun or from the Open Source community. Think "J2EE container but for a Desktop", not with server-side services, but with client-side services. Instead of JDBC, JMS, JTA, etc., it will provide binding, validation, look and feels, event communication, dialogs, server (data source) hooks, plugin APIs, dynamic window management, docking framework, preferences, UI metadata, etc..

  GUI development today is like server development 15 years ago - everyone reinvents the wheel, there's no framework and no reusable components or a container to run them in.

  Just like J2EE, once the contain and its services are specified, then more developers will come on board knowing it's a solid boat to jump into. Then the OpenSource community and the paid source community will add value (neither adds much of anything today except JGoodies and JIDE).

  When the tools are available to make it easy to program on top of the framework, then lots more developers will jump on board. At that point, ,most of the above-mentioned problems with go away. With lots of people clamoring for new FileChoosers, WebStart updates, etc., then these problems will get fixed. When the framework is avilable, then lots of devleopers will provide *reusable* components conforming to a container's API, making their own JFileChoosers, etc.

  Sun has spent countless person-hours on server-side APIs and their implementations, no wonder why they are nearly universal. From what I can tell, Sun has about 10 people devoted to Swing, maybe only 5 that have spent many years on it. Most of the time they work on smal throw-away projects, not anything near as rigorous as an EMC Control Center or an IDE (It's apparent that NetBeans and Swing folk don't mix). JDNC is a very good step in the right direction, but is still lacks broad vision and strong foundation grounded in real customer requirements. It could get there, but without a huge commitment by Sun, it won't. SpringRichClient may be a better step since it has a foundation and is grounded in the real world, but that has a long way to go too.

  Posted by: michaelbushe on April 07, 2005 at 08:32 AM

• The single most serious complaint about Swing I have is that Sun has failed to accept the offer of the Eclipse project to replace AWT by SWT.

  Swing based on SWT would be great, and the Eclipse guys claim that it could be done. Why not pick up this discussion with Eclipse again?

  Posted by: marc_domenig on April 07, 2005 at 08:42 AM

• I do ship Swing applications, in fact my entire work is based and focused on and around Java. My web site at www.lightdev.com runs on Linux and Tomcat 5.5, its is running an own CMS in Java, online services in Java, contains many Java open source projects as well as commercial Java products. Everything is documented in JavaHelp with an own help authoring tool written in Java. The JavaHelp documentation is transformed to PDF manuals with - guess what - an own tool written in Java.

  I do all this because I love Java - don't get me wrong - but although:

  
  the JRE does not include JavaHelp so it is necessary to ship JavaHelp with every desktop application inorder to provide proper documentation.
  it is difficult i.e. expensive to make it simple for the end user to install and run a Java application. I do use Webstart but it requires to have Java already.
  Swing is inconsistent in terms of class and method structure and some parts are poorly maintained
  HTML is a nightmare, completely outdated, ridiculous that Sun positions itself as [i]the[/i] web company with only HTML 3.2 support and without HTML 4 or proper CSS support in Java.

  
  And one last comment: Don't support Eclipse or SWT, I think it is the wrong approach.

  Posted by: uhilger on April 07, 2005 at 02:32 PM

• I have another observation about the pluggable look and feels. Successful applications which use there own look and feel e.g. Winamp, Mozilla etc. do not use a custom L&F for the file chooser. They use the native filechooser. Even if I want to switch to another look and feel for my Swing app I know that this L&F will also be applied to the file chooser and make the filechooser look totally foreign to the user. All the icons etc. will be different. There are some components that the user expects to look a certain way. The file chooser is one of them. I even had someone once who opened the metal file chooser (in 1.3), looked at it and wanted to know what it was.

  BTW looking at previous posts it looks like all posts containing an apostrophe have been truncated.

  Posted by: jdolphin on April 07, 2005 at 10:56 PM

• Here's another important feature that's missing from Swing: Scrollable menus

  Any good application framework needs to support this. Font and Bookmark menus will often have so many items that they won't fit on the screen. All GUI frameworks will put scroll controls at the top and bottom. But whoever designed Swing's menu support never thought of it, and they still don't bother to support it. How am I supposed to handle this? The JMenu specs were apparently written by someone who doesn't know much about menus.

  An application framework can't assume the developer will have ideal conditions. It needs to be flexible enough to handle long-shot cases like this. It needs to give developers freedom, not place restrictions on them.

  Posted by: miguelm on April 08, 2005 at 02:43 AM

• I here a lot of people saying that they ship there applications with Swing and such. That nothing is wrong with Swing and that there applications are world class. I do not doubt that their applications are world class but here is the real issue. Would anybody here develop there application in Java or .NET with the following requirements:
  Very strict deadline
  Application must communicate nicely with business productivity applications
  Application must be leverage legacy codebase and/or components
  Application will run on Windows based machines
  I dare anyone to say that they would chose Java over .NET. Often times developers develop applications for themselves. In other words, they develop applications in development environments that are familiar to themselves in the process producing applications that are unfamiliar to users. Say what you will Java is slow. Slow compared to comparable applications written in C++ and C#. The reason being is that Java is not optimized to any particular OS. Here is the big question, if I can develop an application that is optimized for Windows and at the same time run just as fast on Linux, Unux, and Mac who love a platform like that? I know I would. Well, with open source releases of the .NET framework you can do just that. It would serve Sun better if they would optimize Java to run on particular OSes as oppose to generalizing this process. That way I can run the optimized jvm on, say, Linux, and my code written for Windows will take advantage of these optimizations when compiled and deployed there. In other words Sun should create multiple compilers optimized for a specific OS. Does Sun do this already? Yeah, sort of. They do ship multiple compiler versions but I would argue that none are optimized for the underlying OS.
  Again, let me stress that Java is a great platform, but only if you want your applications to run on any OS. But, .NET accomplishes the same by standardizing the framework and compiler. So, at this point Java can no longer stake single claim to it motto of "write once, run anywhere." Not only that but I am able to write piece of applications in other .NET enabled languages such as C++, VB, and Perl and run them without a hitch. This presents a major problem for Java moving forward.

  Posted by: ahives on April 08, 2005 at 04:01 PM

• Swing should look at how Apple's doing it on Mac OSX.
  Apple goes as far as to implement their own JVM.
  Mac OSX has had OpenGL accelerated GUIs for years, and
  it extends to their implementation of Swing on it.
  Longhorn's Avalon is doing the same right now. The
  Java2D (which all Swing rendering depends on) team
  is doing the same, but they need to do it better and faster,
  and they need to make it work well along with JSR-231.
  Otherwise I really see no hope of developing real-time
  media applications on the desktop. Anyone know of a
  usable video editing application written in Java/Swing?

  Posted by: rexguo on April 08, 2005 at 09:19 PM

• michaelbushe,

  You are right! Swing needs a solid framework for application development. One that provides an easy path to expand upon, yet supports a wide range of *common* functionality such as help, preferences, meta data, user configuration, authentication, and a lot more.

  The Platonos Project (www.platonos.org) aims to achieve this exact goal. While its taking a while to get there, we are slowly heading in this direction. Our core component is a plugin engine that is very similar to the Eclipse plugin engine yet uses no code from that project. Our application framework is built around the engine, with every aspect of the framework being plugins.

  However, we recognize that many others have also gone down this path. For example, the FlexDock docking framework is a very usable open-source alternative to JIDE. There are alternatives to JavaHelp, we have built up our own JFileChooser alternative, and yet there are others that have built custom native luanchers with immediate splash screens and such. All of these things we will try to incorporate into our framework, including as many open-source (non GPL based) components we can muster up as well.

  We are working on tools support as well, such as a plugin project wizard tool to help rapidly assemble plugin projects, even deploy them into a running application.

  miguelm,

  As mentioned above, our framework is aiming to appease a number of areas lacking in the Swing development community. I have been slowly working on a more dynamic menu system. With the use of plugins, it's necessary to allow for some more specialized needs for menus. Because plugins can load in any order, you don't want a File -> Exit item showing up above the File -> New, for example. Also, saw a demo out there written in Java that shows a few different styles of menus, including not only scrollable, but a sort of "zooming" scrollable menu that you could literally have 1000 tiny items, and as you move down a small portion of it zooms in, sort of like the Mac OSX Dock does when you move over it and the icons sort of baloon and enlarge via animation. Also, with the ability to have dynamic menus comes the ability to hide/show items on the fly, including showing a short/long menu, and showing arrows to scroll either way. It is far from ready, but hopefully we'll get that working sooner than later. Any help is of course appreciated.
  

  Posted by: buckman1 on April 09, 2005 at 07:31 PM

• hi,
  i feel swing is low on performance.

  Posted by: annacoder on April 10, 2005 at 12:02 PM

• First of all, we do deploy a Swing App (client/server). There is no real show stopper. BUT - we had to fix or work around a lot of bugs (we spent weeks). Some bugs (explicit port for rmi) require a "workaround" like "you have to install the server on a dedicated machine to be able to reboot..." but this is not a swing issue...

  Distribution is done via InstallAnywhere with bundled VM, since we test/develop against one VM Version only (actually 1.4.2) and using other VMs cause some unwanted effects. InstallAnywhere Now! is a good option for every Java-Swing developer to deploy their applications for free.
  What would most help improoving our Application is to solve all this Bugs in JTextPane and support HTML4 and CSS. Sure, solving all other Bugs is welcome too. We have nearly no good reason to switch over to Java5 since there are no important Bugs fixed and we need none of the new features to do our Job!
  

  Posted by: schlm3 on April 11, 2005 at 12:39 AM

• Allow me to say a few words about the layout managers. They're a great idea. I love it when I get them working well, and the user can resize the window at will and the layout managers keep everything the right size. They're quite powerful, and they generally work. The trouble is that I need them to always work. For example:

  What are setMinimumSize() and setMaximumSize() for? They certainly don't set the minimum or maximum size. According to the Swing team, not all LayoutManagers support them. That's quite an understatement -- I don't know of any that support them. And they would probably be pretty useful.
  After I put a JTable into a JScrollPane, it works great when I put it in the center of a BorderLayout. But that's the only place I've found it to work. Just putting a small table in the bottom (which I needed today), didn't work at all. It took up way too much space, even after I had called setSize(). Somewhere deep inside, it sets the viewport to some arbitrary wrong size. I found it once. What's it doing there?
  While we're on the subject of JTables, why is their so little support for row headers? I finally found a way to make them work, and encapsulated them into their own class, and I can finally use them at will. But I shouldn't have to struggle to do something so simple.
  I've already described the insanity of BoxLayout. My workaround is to recursively pack objects into the North or West side of a Border Layout. I shouldn't have to do this.
  Here's another tip on using the BoxLayout, just to illustrate how bizarre it gets: I subclassed it as DebugBox, which puts a line border around every component. The borders range from red to blue, depending on their Horizontal or Vertical alignment property. Then I can finally see which components are causing the alignment problem. Works great! But why on Earth do I need it?

  
  The truth is I spend a lot of time just struggling with ways to layout my components. They're fine for doing very standard stuff, but If I want to invent novel, useful UI idioms, they often work against me.
  (If you'd like, I could say a few choice words about the text components, too.)
  

  Posted by: miguelm on April 11, 2005 at 08:28 AM

• Allow me to say a few words about the layout managers. They're a great idea. I love it when I get them working well, and the user can resize the window at will and the layout managers keep everything the right size. They're quite powerful, and they generally work. The trouble is that I need them to always work. For example:

  What are setMinimumSize() and setMaximumSize() for? They certainly don't set the minimum or maximum size. According to the Swing team, not all LayoutManagers support them. That's quite an understatement -- I don't know of any that support them. And they would probably be pretty useful.
  After I put a JTable into a JScrollPane, it works great when I put it in the center of a BorderLayout. But that's the only place I've found it to work. Just putting a small table in the bottom (which I needed today), didn't work at all. It took up way too much space, even after I had called setSize(). Somewhere deep inside, it sets the viewport to some arbitrary wrong size. I found it once. What's it doing there?
  While we're on the subject of JTables, why is their so little support for row headers? I finally found a way to make them work, and encapsulated them into their own class, and I can finally use them at will. But I shouldn't have to struggle to do something so simple.
  I've already described the insanity of BoxLayout. My workaround is to recursively pack objects into the North or West side of a Border Layout. I shouldn't have to do this.
  Here's another tip on using the BoxLayout, just to illustrate how bizarre it gets: I subclassed it as DebugBox, which puts a line border around every component. The borders range from red to blue, depending on their Horizontal or Vertical alignment property. Then I can finally see which components are causing the alignment problem. Works great! But why on Earth do I need it?

  
  The truth is I spend a lot of time just struggling with ways to layout my components. They're fine for doing very standard stuff, but If I want to invent novel, useful UI idioms, they often work against me.
  (If you'd like, I could say a few choice words about the text components, too.)
  

  Posted by: miguelm on April 11, 2005 at 03:37 PM

• miguelm,

  TableLayout is your friend! I don't use any other layout.. ok, BorderLayout sometimes. Seriously, even though so many love JGoodie's FormLayout, I have used both and find TableLayout easier to use out of the box. Both are very good and FormLayout is an extension to TableLayout I believe. Just set up a double[] for the rows and double[] for the columns, specify integers for absolute width/height, fractions for percentages of left over space, or specific values from the TableLayout constants to fill the entire area and more. I wish Sun would have adopted TableLayout in JDK 1.4! Would have made my life SOOO much easier.
  

  Posted by: buckman1 on April 12, 2005 at 01:02 AM

• I complained in a previous post about the JFileChooser, and was thinking about it a little more. I'm wondering if it wouldn't be better to abandon the goal of trying to support the look-and-feels of the different native file choosers, and instead focus all efforts into a single style of file chooser. I know people like to treat L&F issues like they're life-or-death issues -- "Oh my God, the Swing JFileChooser shade of blue isn't exactly the same as the Windows file chooser shade of blue," or "The Mac L&F Open Button in Swing is positioned one pixel to the left of where it actually is on a Mac, and that's why Swing will fail in the marketplace," but I think these types of complaints - along with the "Swing is too slow" complaint, are just reflexive, and not real issues. As long as a file chooser is intuitive and easy to figure out, you're in good shape. If the fonts, colors, and rounded edges don't exactly match what you're used to, is it really that big of a deal? Are people really so helpless that they can't make a small adjustment? If a guy has two books, each with a different font, does that mean he won't be able to read one of them?

  Maybe a good analogy is browsers. They all look and act a little differently, depending on their manufacturer, version and OS, but I don't think people have much of a problem going from one to another.

  What we have in Swing at the moment is a set of file choosers that "sort-of look like" native file choosers, but when you try to use them, seem very amateurish and lack basic functionality. This upsets everybody, and makes it difficult, if not impossible, to come up with a high-quality Java desktop applications, like word-processors or spreadsheets, that depends heavily on a working file chooser.

  I'm not the first to suggest it, but it might not be a bad idea to stop making a futile effort to mimic the native look-and-feels altogether, and just focus on coming up with a single overall Swing L&F. You can start with and then extend something like GTK or Ocean. I have no particular preference. One good L&F that actually works is better than a bunch of not-quite-there implementations that everyone complains about, all in pursuit of a goal that really isn't that important anyway.

  On another subject - it seems pretty clear that the the initial hope of having one JRE on a machine able to run lots of different Java applications isn't panning out. The reality is that to ship a Java 1.5 desktop app, you have to include a 15 Mb JRE with each app, and it's only going to get bigger with each JRE version. Just imagine downloading Adobe Reader every time you wanted to download an Adobe document. Yet this is roughly the type of thing Sun makes us to do ship a Java desktop app. The byte-code for the application I am working on is less than 1 Mb at the moment, and I vaguely recall that it's about 4-5 Mb when compiled down to machine code. It really bugs me that I have to ship a JRE that's three times the size of my application. It discourages the creation of little Swing desktop utility applications if the smallest size file you can ship is 15 Mb. I don't know how hard it would be to break up the JRE, but it sure would be nice if I could ship only the basic JRE kernel and the JRE libraries that I needed. Again, I'm not the first to suggest this. If I'm not doing any database-related coding, why do I have to ship database-related class files. If I'm not using a LinkedHashMap or HTMLEditorKit, why can''t I leave those out of my distribution?

  Posted by: ssinai on April 12, 2005 at 01:13 AM

• I feel like the problem is that Sun simply hasn't devoted enough resources to the last 10% of Swing that would make it a viable option. The fact that there are critical bugs that have gone unfixed for years is incredibly frustrating. The inconsistancies with the behavior of native components is still at the level where it would confuse most users. We spend thousands of hours working around these problems, having to rebuild huge parts of the framework because of some private methods. Sun needs to hire some windows ui programmers and fix these problems.

  I also feel like being tied to the platform core has been sometimes bad for Swing. Particularly if it delays new features and bug fixes to arbitrarily correspond to the larger release strategy. When I find a bug in Swing, I often don't bother even checking the bug parade as it's likely to have been found and have sat there for a year already and there's no way I can wait for it to be fixed anyway. If MS or Apple did this to their application developers there would be a revolt. Us Swing developers simply count it as part of the price and spend nights creating workarounds. See the following for more details: https://winlaf.dev.java.net/release_0.5.html

  For my money, I would say vastly improve Java WebStart, Swing L&F consistency, HTML rendering, JFileChooser, and component customizability and I'll be interested again. Take years to do it and I'll have moved on by then.

  Posted by: ghinkl on April 15, 2005 at 07:36 AM

• Another important factor in choosing tools is desktop integration. You can't imbed a native control (e.g. browser component) in a Swing app without it punching a hole through the lightweight components.
  I am currently working on an app that needs to have a media player imbedded in it. JMF is slow and making sure it is installed on the target machine is tricky. Despite the fact that I have been programming Java for six years it is faster for me to write this app in C# using VS.NET. Even more remarkable since I have hardly ever used C# before. It is incredibly easy to drop a media player component onto a form and associate a file with it. I would much rather be able to imbed the native media player for each platform using JDIC and drag and drop it as a components using Netbeans (assuming Netbeans improves their visual designer as promised).

  I am also interested in accessing the Google desktop search APIs, but that isn't possible without major pain in Java either - I wind up using C# even though I know Java much better.

  Posted by: jdolphin on April 18, 2005 at 12:39 AM

• Here at Secure Development we do ship a Swing app. It is an enterprise application for scheduling and routing field service technicians. To see a flash demo visit http://www.securedevelopment.com/products/SRP/demo.
  Our customers love it as it allows us to provide them with a rich user interface.
  Look for a browser version shortly.
  

  Posted by: kbsimm on April 18, 2005 at 08:52 AM

• Joshua, as the stream of comments seems to have slowed down I wonder if you are planning to summarize and give your reaction??
  As developer of Swing applications for internal company use my concern is not at all with startup times; java performance; footprint, lack of (too complicated) application frameworks etc., but my personal priorities would be:
  * A java or netbeans module which would pack every application in one exe, including the used classes in the jdk and utility jars. Keeping everything in sync, even in a controlled environment, takes a lot of (not very productive) time.
  * Swing components for:
  - html rendering
  - pdf viewing
  - date picking
  - file exploring
  - image viewing
  should really be standard issue. ASAP, please.
  

  Posted by: jancarel on April 25, 2005 at 01:32 AM

• I've been shipping Swing apps since the late 1990s running cross-platform on Windows, MacOS, Linux and Solaris, and demoing the applications live to clients around the world. Without exception, the response has been "Wow" - that is great software. So, for sure, there is nothing fundamentally technical (despite a few headaches as the Java platform has been developing) in the way of people shipping great Swing apps.

  In my experience of talking to people about Java pretty much since its inception, a number of isses have cropped up consitently:

  o Graphical IDEs. If developers are used to using graphical IDEs to develop their UIs, they've had problems with Swing - because historically, the graphical IDEs for Java have kinda sucked. Teams working with me have always been xemacs guys so haven't had this problem.

  o Ease of use. The concepts involved in developing cross-platform UIs (which Java has obviously need to support) are a bit more complicated than the average developer is used to thinking about. For example, many people see layout managers as a nuisance, rather than a powerful tool.

  o Misconceptions. I've probably had hundreds of people tell me that "Java doesn't work" in the last five or six years. There's are so many misconceptions out there about Java - ranging from it being "impossible to configure because of the need for multiple VMs which you can't have", through it "not being read for prime time", to the classic "of course, Java is good on the server side, but you can't develop GUIs with it".

  So, from what I've seen, I guess the reasons for people failing to develop Swing apps include: the developer tools for the masses have not been good enough; Swing is too hard to learn and use for the mass of developers; and too many people belief the myths, so they don't even try.

  Posted by: psynixis on April 26, 2005 at 09:00 AM

• We ship our application with an included jvm. We also use java3d which needs to be installed on the jvm, thats the main reason why we include the jre.
  check out our BT_4Dsign Demo Version of our application (Windows Installer only available at the moment).

  Posted by: suppechasper on April 28, 2005 at 07:40 AM

• BT4_Dsign Demo application: http://www.aec-ii.ch/forschung/bt/downld.html

  Posted by: suppechasper on April 28, 2005 at 07:41 AM

• We ship our custom applications internally. Our applications need to handle and display terabytes worth of data and generally do so with few performance issues.

  A framework around Swing would be nice.
  How about fixing some of the five year old Swing bugs.
  Many of the deployment issues listed above are not a concern.
  SUN needs to focus more on client side applications.
  We are looking at moving to Eclipse RCP but we are finding many problems and the learning curve is steep.
  We run our applications on Solaris, Linux, and Windows. Eclipse RCP has issues when it comes to multiple platform support. SWT works best under Windows.
  How I hate X.
  Different platform L&F isn't a big issue with our users
  Slow startup time is a big problem.

  For those longing for the good ol'Microsoft development tools/languages, just remember that they have a long history of dumping their tools. Microsoft dropped Visual Basic like a hot potato when it went to .NET. How about DLL hell for Windows. X is overs 20 years old. Remember Open Look, Motif, CDE, etc. All development/runtime environments have their own drawbacks.

  
  The grass on the other side of the fence isn't any greener, its just implemented differently.

  Posted by: dak2009 on May 05, 2005 at 08:57 AM

• Everybody has something negative to say about Swing. Yes, I agree deployment is a problem. But, consider this: .NET and SWT use native widgets underneath. When you have a native ListBox, it is going to duplicate the data that you present to it. You will hold a copy of the data in your app logic, plus the widget will hold another copy. Try to have a ListBox or JTable like component in .NET or SWT display a view of 1 million rows. That is easy in Swing. You don't have to have 1 million objects, you just need the portion that is visible. The rest, you can handle reading from a database etc in your model. These kinds of problems come all the time. SWT, or WinForms etc is not the best on their own either. Anytime i go to Visual Studio, I miss my LayoutManagers. Get real folks, many GUI's written in Visual Basic plainly suck. Their components are not rich in extensibility or capability either. Dare to write multithreaded GUI in MFC? Are you going to have your GUI freeze just because your database is not responding, network is down? All of these are easy to manage with Swing. But with the simplified approaches of other Libraries these data duplication, multithreading etc problems remain unsolveable in many cases. Yes, JTable is simple but consider this: JDNC has JXTable or something and they have overriden every protected method and closed alot of the customizatons paths we could use. JDNC is more like a specific solution, it is actually harder to take JDNC components and extend them without breaking them, or they have simply did not think about deriving new classes for new ways, because some variable or method is private... In .NET, how do design a GUI that can re-size itself in a meaningful way? How do you extend these components in subtle ways? When it is time to extend, where is the source code to learn inner workings? Yes, in VB you can write a simple application easily, but you cannot easily customize the components to your needs. Same thing in SWT. How can somebody ever like every constant to be in 1 file? SWT.THIS, SWT.THAT??? How the hell do i know which of those constants are applicable for my current function call? I want to create a ListBox or a CheckBox and how do I know what kind of style constants available for that "Button" (every damn thing is a button??) Why is it not CheckBox.SOMESTYLE, but it is SWT.SOMECHECKBOXSTYLE ??? I get lost. Everybody says deployment is a problem. How come nobody mentions deployment problems of shipping the native dll of SWT ???
  When Java VMs start sharing already loaded classes in memory, Swing will perform better too. JVM is not a good desktop player and it should not be a Java Virtual Machine anymore. It should be called JVP=Java Virtual Process. It should behave accordingly and not monopolize the OS memory. We also need a good installation model where on a given system there is only 1 JVM per version: 1.2.2, 1.3.1, 1.4.1_02 etc, and my application should have a say on which one to run. That's all we need. If I tested my application with 1.3.1 and it was fine, just because user installed 1.5, what is the point of risking my stability just because 1.5 is there???? Also, have stable URL's for JRE downloads where we can write an installer (or you provide an installer as a component), download your JRE and
  install it as needed. Other than these general Java issues, Swing is good. Also, you have screwed up generics, but it's too late now. Ok, while at it let me add that I do not get why Java does not have conditional compilation. You leave it out but still feel the freedom to break interfaces such that we cannot compile 1.3 code with 1.4 anymore? Anybody who implements java.sql.Connection, or java.sql.ResultSet ??? Please either give us conditional compilation or give us ResultSet1_4, ResultSet1_5 etc. Once you ship an interface, you need not change it right and left. This way we can write code that compiles on both 1.3 and 1.4. Also keep in mind, if you compile in 1.4, it is not guaranteed to run in 1.3. So we need it. Summary: Swing is good, just fix Java and the JVM. While you are at it, add some kinds of static linking too. I am tired of runtime problems when my compiler gives OK. Look at .NET, they don't ship individual classes, they bundle them in DLLs.... Make us link against a jar etc. After obfuscation, who would ever get a chance to ship a single class file and take advantage of class file granularity? If you are not going to do anything, make everything about Java Open Source, so that someone might do something.
  

  Posted by: demir4 on May 27, 2005 at 10:34 PM

• Novell GroupWise Messenger (an instant messaging solution) ships a cross-platform client for Mac and Linux written entirely in Swing. Users are very happy with it, and it works well on both platforms. Some things were a lot harder to write than they should have been, but other things were easier than expected.

  Posted by: str8oz on June 23, 2005 at 08:36 AM

• I would argue that you absolutely MUST bundle the JRE.

  - You can't control which version of the JRE your application will use, unless you bundle it.

  - QA testing needs to exercise your product on a specific JRE. If QA says it works on 1.4.2_08, then you have to bundle that JRE. Otherwise you risk having the application crash ungracefully under a newer JRE.

  - QA can't sign-off the application if it tries to use the latest-and-greates JRE on the customer's box, since they never tested that JRE.

  - For example, you have tested your Application using JRE 1.4.2_08 and finds it works OK, But it breaks on JRE 1.5.0_03. So you MUST bundle 1.4.2_08.

  - Will your application work on 1.6.0_02? How about 1.7? You can't test it, so you can't risk using a non-bundled JRE.

  - Testing deployment configurations is often time consuming, especially if you support multiple DB vendors and upgrade scenarios.

  Posted by: metalotus on July 29, 2005 at 11:55 PM

• Most contracts i have been working on are all deploying Swing apps, woohoo! Complaints by developers were that (1.4) Swing components are buggy when you made them do backwards somersaults, and old bugs not getting addressed (presumably because of Sun's "focus" on web/JEE in the dotcom era which is understandable). No complaints from clients - Swing looks beautiful and is performant and just gets better (in every department)

  My impatient wish is that JDNC/SwingX is more mature/extensive already - we need no-brainer high level components and frameworks for throwing together business apps (with data binding) using best practices and patterns

  I suspect we lack these after 10 years because AWT/Swing was envisaged as a web/consumer/desktop application platform rather than an enterprise application presentation platform. It appears that much work has been done on JEE/EJB, and relatively little on Swing as an presentation platform for JEE applications.

  Also I think that WebStart is not delivering its potential. Getting WebStart really slick and integrated to every browser and platform, to deliver no-brainer one-click Swing application delivery via the network (with JRE auto-update and partitioning and a whole bunch of feature-candy for real world application delivery), would do much for Swing adoption

  There is one company i worked for recently that ships a JBoss application when it really really should be Swing (for internal retail/stock system with 1000+ sites) They went web-based because of everyone's infatuation with the web as a platform (please, stop it! ;) And see above comment about boosting WebStart to leverage this infatuation to Swing's benefit -- ie. using "the web" as a Swing application delivery platform, not an application platform (for intranet enterprise applications)

  So in conclusion we need JDNC, and blueprints, and lots of high level components -- to clearly illustrate and demonstrate and tutor how Swing apps can be easier to develop and maintain, compared to a dogs breakfast of java/EJB/JSP/Javascript/HTML that are web applications, and a better user experience to boot.
  

  Posted by: evanx on April 26, 2006 at 04:23 AM

• Some components that shouldn't be missing (and I miss at every project I work with):

  - MultiRowLabel
  - CheckboxList
  - CheckboxTree
  

  Posted by: montechristos on June 19, 2007 at 01:51 AM

• Some components that shouldn't be missing (and I miss at every project I work with):

  - MultiRowLabel
  - CheckboxList
  - CheckboxTree
  - Multi-column sorting JTable

  Posted by: montechristos on June 19, 2007 at 01:51 AM

• I'm a shareware developer (part-time), and in that role I ship quite a few Swing apps. I'm looking into WebStart (or applets, for that matter) as a via option for a for-pay distribution channel, but in the meantime I distribute my apps as traditional desktop applications. I wrote a little article to document how I package up and distribute everything.

  Posted by: taubler on August 21, 2007 at 09:59 AM

This work is licensed under a Creative Commons License.