Jonathan Simon's Blog

Swing: People still aren’t getting it!

So far, of the people I’ve brought in, no one has been able to answer a simple Swing threading question. Several even suggested to use SwingUtilities.invokeLater() for expensive work - not knowing it’s actually executing in the Swing thread. I’m making a point of this because it highlights a disconnect between the design of the Swing API and its users.

Is the Swing API too complicated? Maybe. Programming in VB is a lot easier. But is that the goal? There has been some talk about making a façade or wrapper around Swing. Interesting.

What about the user base. Should Swing only be attempted by devoted "Swingers"? I've seen that casual developers have a pretty hard time, or just simply do things wrong or inefficiently (this also leads to misconceptions of performance, etc.). If this is the case, it goes against the Java Desktop initiative. If Sun wants Java running on desktops everywhere- Swing has to appeal to all walks of life- not just the hard core types.

What about communication. Maybe the documentation is a problem. Do JavaDocs not cut it? Maybe this isn’t an API issue. I happen to think that JavaDocs is great at helping you understand the API - but don't necessarily help you use it properly. Maybe something is needed in addition to JavaDoc. Maybe a format for simple example applications is in order, or just a high quality repository for Swing applications that people can learn from.

Just to wrap up: Either the Swing API is too hard to use, there is a misconception about the user base, or Swing is poorly explained. Either way- there is a big community disconnect and I think a lot of people don’t “get” Swing. For Swing (and desktop Java) to be sucessful, we have to nail this once and for all.

Comments

• I feel your pain
  It does seem like there are a lot of people out there that are using the Swing APIs just plain wrong. I wish I knew the answer to this problem. Unfortunately the Swing APIs take the wrap for being hard to use. Personally I find the Swing APIs extremely easy and clear. You can do things simply or drill down to very complex levels if you so choose.

  I personally feel that people are too used to drag and drop GUI design and when confronted with something more complex, they shy away and refuse to take the time and learn the APIs.

  I hope that the API does not get "dumbed down", that would do it a great disservice.

  Posted by: mzarra on May 10, 2004 at 02:55 PM

• Swing is way too complex
  Compare Swing to anything on the server side. Swing is way too complex. I am an occasional Swing developer but I always find that nothing in Swing is simple or intuitive. I tried to write a simple program that simulated the functionality of WinZip. It took about a day in C# which I barely know. I gave up trying to do it in Swing when I found myself writing half a dozen classes just to dynamically add columns to a JTable. Nothing is simple unless you develop with Swing constantly.

  Posted by: tgpaul on May 10, 2004 at 05:13 PM

• threading, plus...
  I've been programming Swing for some years, and I agree that Swing can be irksome - there's no 'right' way to do things as basic as attaching a behavior to an interface widget. That said, it's possible to write good applications in Swing, and ones that are responsive. Regarding threading, this is a serious problem with Swing. Everyone who reads the tutorial knows you can't perform long actions in the event dispatch thread or you freeze the UI. The typical solutions like the Swing worker class given in the tutorial have flaws as well. I had nightmares until I discovered Spin (http://spin.sourceforge.net/). It clearly separates business logic and UI, and it works great! To be honest I understand about 80% of what it's doing, so it looks like magic, but what a great boon to Swing.

  Posted by: cornell on May 10, 2004 at 05:59 PM

• Swing Docs & JavaBeans
  I find the opposite to be true with JFC documentation. The Java Tutorial provides excellent basic coverage, but in-depth examples and articles are hard to find (e.g. implementing your own JTree models; drag and drop) even with vast Internet resources. Compared to the number of J2EE books, the number of JFC books that offer more than API overviews are few. Is it absurd to say that JFC is the EJB of J2SE? Not if you go by the repeated posts of "people don't know how to program Swing properly" I see. I don't find JFC that difficult on average, but I still occasionally struggle with getting enough information about how to approach some JFC topics after nearly 8 years with Java.

  Secondly, what in the world happenned to JavaBeans? I recently became (re)interested in providing JavaBeans for my API to assist developers build quickly and found that almost all information on JavaBeans ceased after about 1998/1999. Yet there are still plenty of holes in the topic to prevent even experienced developers from easily packaging their software as visual components. I think that the sparse adoption of JavaBean technology in the desktop realm hurts Java on the desktop. This is precisely the technology that would (and should) provide the transition between rolling your own in JFC and the "just get something done" productivity that we could all benefit from.

  Posted by: ctsui on May 10, 2004 at 10:27 PM

• Swing /is/ complicated
  Swing /is/ complicated - to produce good results (for both the user, and future code maintainers) you need to understand threading, model-delegate, and often basics of rendering/co-ordinate systems and fonts

  You also can't avoid hitting the fact that its based on AWT, and that there is an overlap in method names inherited by Swing classes that no longer do things

  Repainting, and layout methods are extremely confusing. I've read a weighty book about this and think I understand now, but this is totally unacceptable and probably based more on the history of Swing (and AWT...) than anything else

  Whether knowing about these things is necessary to produce the kind of applications that are typically wanted is a different question (I've not used VB but take it on trust that its easier to use)

  LayoutManagers are also complicated and not uniform in their usage, and getMinimum|Maximum|PreferredSize are confusing since you don't know if they will be respected without trawling the API

  In summary, imho, what is needed is either a GUI building tool, or a much simplified API that gets what 80% of people want done extremely trivially, and when you really do need the last 20% to customize tree rendering, or (for the brave) writing a full component then you can delve back into Swing's full API (and then you'll probably be grateful for it!)
  

  Posted by: asjf on May 11, 2004 at 04:41 AM

• I think you may be right
  The more I consider the Swing API the more I find it to be overly complex. Don't get me wrong, they designed an incredibly powerful and flexible API, but for day to day use it's pretty complicated. The API for JComponent alone is overwhelming. Perhaps a wrapper API around Swing would help. Something that would hide the complexity but still let you touch the underlying API when you need it.

  It's also a documentation issue. There simply aren't many books or tutorials that explain how to do all of the intesting things, or that explain the design patterns to use. It's easy to build a Swing GUI, it's very very hard to build a good one that is maintainable.

  I've started a wiki to capture all of the existing knowledge out there, and I've put up a wishlist of ideas for how we can fix the situation. It's more than just some new widgets and better graphics. We need to work on how people design Swing applications. (hmm. I think I smell another article)

  Posted by: joshy on May 11, 2004 at 06:20 AM

• How do you do threading in VB?
  >So far, of the people I’ve brought in, no one has been able to answer a simple Swing threading question.

  >Is the Swing API too complicated? Maybe. Programming in VB is a lot easier.

  I am not a VB expert, and perhaps threading in VB is a piece of cake.

  But in my limited experience with VB and ASP.NET, it is trivial to do the easy things. When you have to do the hard part of your job, you fall off a cliff, and you either die or you transform yourself into a wizard with superhuman powers, reinventing lots of code.

  The way to make Swing easier is, frankly, to provide what VB has--a great GUI builder tool. The VB API isn't easy either, they just hide it behind a tool. Why isn't there a decent GUI builder for Swing? Now that would be a good topic for someone's blog.

  Posted by: cayhorstmann on May 11, 2004 at 07:23 AM

• I feel your pain
  The ease of use of Visual Studio does take a lot of the pain away, but I wouldn't say that's the only thing.

  I've been whining for years that Swing needs to have nicely featured 'vanilla' versions of various controls.

  For example, I want to adda table control to my form which has:

  * movable columns
  * sortable columns

  You can write it in Swing, but it's going to take some time and you have to be pretty adept. I can completely appreciate that Swing allows you to be much more flexible, but I think the 80:20 rule applies here.

  Posted by: archangel on May 11, 2004 at 08:28 AM

• What about Buoy?
  So, what do you think about Buoy?

  Posted by: coxcu on May 11, 2004 at 08:31 AM

• threading, plus...
  Spin rocks. If I was on the Swing team, I would point people towards it.

  Posted by: coxcu on May 11, 2004 at 08:36 AM

• My 2 Cents :)
  I have to agree with some people that in order to do above average tasks in Swing, you really have to do some research. However, if you build Swing GUI's all the time, it's very easy to become familiar with the methodology behind Swing (MVC).

  I consider myself as an intermediate/advanced Swing developer; however, I feel that there is not enough information out there like there is with J2EE about patterns and anti-patterns for Swing applications. Thankfully I use JGoodies, which is a wonderful framework for GUI building. It also has a handy class for threading as well. The guy behind it is very talented at Swing and has strong knowledge on how those applications should look and be built.

  I think for a lot of users who prefer a tool to build GUI’s aren’t asking for to much, but at the same time, you have to realize when you build a GUI, especially for a customer, they are only going to want it improved, which means maintainability. It’s hard to achieve that with a form builder.
  

  Posted by: mjgreene550 on May 11, 2004 at 09:06 AM

• Put what we know together
  Swing has been around for years. People know how to use it, and there are plenty of examples now of components and full applications that use Swing well.

  So: the knowledge is out there. What I think we need is to pull this together in an organized fashion. I've started to sketch out my own ideas for this, but nothing solid so far.

  People mention VB, but what VB offers is not just a GUI builder but a set of decisions about how an app should be built. If you have a drop down list, and you need to bind it to the results of a SQL query, in VB this is easy to do, as someone made a decision for how binding should take place. VB and such fall down when the architectural/design decisions they made don't suit your particular situation--so you end up grinding through miles of code and documentation to figure out a workaround.

  Part of the problem with VB is that it is a commercial package owned, developed and designed by one team in one company. There is no real competition in that world for alternate methods for, example, data binding.

  What Swing gives us are the basic tools to build any sort of app we want. If we want our app to be configurable, localized, enabled for plugin-extensions, scriptable, all of that is possible. What we need is 1) healthy competition on the means to do this and 2) some oversight over the competition process so that solutions that are widely accepted are promoted.

  We work from the ground up. I used to write my own configuration utilities, but now there are great ones that work against any datasource, are truly hierarchical, support objects as values, etc. So you move up to the next level of problems.

  Same with Swing. Take a look at where we are now: what are the difficult problems? What do people bang their head against over and again? A good example is the threading/UI lockup problem. There are several decent solutions for this (SwingWorker, FoxTrot, Spin, among others). Compare those, promote those, distribute those. If they aren't good enough figure out why, build the new solution, let the community vote on it, and move on to the next level of problems.

  What we don't have from Sun is leadership on this issue, and unfortunately both the commercial and open-source communities have voted with their feet. So, Swing enthusiasts: you have nothing to lose. Let's see how we can get started.

  Patrick

  PS--I have a project here on java.net called SwingEasy that is one attempt to work on this...should be uploading some first structured documents at the end of the week. Josh's Wiki idea looks great as well, maybe there will be synchronicity.

  Posted by: pdoubleya on May 11, 2004 at 09:10 AM

• Used to be one...
  VisualAge for Java had a very good Swing GUI tool. Unfortunately, VisualAge itself was a steep learning curve for most people.

  Posted by: gibbleth on May 11, 2004 at 09:23 AM

• How do you do threading in VB?
  You are 100% correct. Threads are a major pain in VB(See Curland's advanced VB). Once you push the threshold, you are in COM Win32 API land (or 3rd party).

  A guy was bashing Swing compared to VB. I asked him how he handled threads. He didn't know what they were. I explained. He said, oh, 'DoEvents'. I said, nope, (similar to Thread.yield()), and then he got it. So how can I do it in VB? he asked. Showed him the Curland book - (lots of Win32 stuff) he said no thanks.

  So how do VBer's survive if they don't address the hard issues we face everyday? (who doesn't need threads?) This is the clincher: VB encourages blissful ignorance - and simply bad practices.

  If you have long tasks in VB, and you don't want to have unresponsive windows, you just mix your presentation, business and data layers: loop thru a resultset, call 'DoEvents' every mod 500, and update the UI in the loop.

  Layout managers are complex too. Don't write code to resize your controls, just stick'em where you want them and make the window unresizeable;)

  The people that use VB who don't want to take this road to mediocrity and bliss really end up bangin' their heads against the wall to get stuff to work right. They become 'VB outlaws' and when they find bugs or unresolved issues, they are told next version=fix, or 'don't do that', or the worst, 'your problem doesn't exist'.

  Their code looks so much like COM/C++/Win32 that they start coding in C++...

  Posted by: d_bleyl on May 11, 2004 at 11:50 AM

• Swing was a victim of deployment and performance issues
  I disagree that the Swing API is too difficult. Sure, there are places where it could be easier to do things but once the API and its methodology is understood- look out. A developer can do amazing things with it. Any developer can understand the Threading issues in about 15 minutes by reading any of the good swing books and tutorials

  I think most good developers didn't bother learning Swing because they were afraid of deploying Java and the slow performance of Java on the client. Thats why, unfortunately we are stuck down the html/jsp client route. Now that these problems are for the most part fixed the perception is still doing damage to client side java.

  I don't understand why some big Java/Swing Sun guns don't write a kick ass desktop app to show the world what it can do. Something like the Apple iApps. a JPhoto that looks and feels better than iPhoto and can run on every platform!

  Posted by: sesuler on May 11, 2004 at 01:03 PM

• most people learn quickly by example
  There are far too few examples of usage in the Javadocs.
  A few embedded (or linked) working code samples to illustrate
  the salient features of the Swing classes would go a long way to
  helping people learn the right way to Swing.
  
  Mel :)

  Posted by: mel on May 11, 2004 at 01:44 PM

• Swing is not finished enough.
  What I miss most in Swing is cohesion; and the feeling that the API had all the attention it should have had.

  The event model of Swing is fine, but very very basic. You need to be an expert to use it. In other words; it misses the polish it could have. Don't make the mistake to see threading as a seperate design from event handling; threading is an effect of a dumbed down design of event handling!

  As is usual if I reply to such topics; I have been playing around with the problem myself for some years; and have looked at all the solutions out there (I noticed Spin was mentioned below, its nice, but does not solve the problem).
  A much more powerful way of handling events in a correct threading model is proposed in the latest stable release of UICompiler ( http://uic.sourceforge.net/api/12/uic/model/UICSimpleAction.html )
  A much more advanced version is in active development (public CVS you can access at http://sourceforge.net/cvs/?group_id=59493)

  I invite you to look at the UICSimpleAction and the classes that extend from it.
  The biggest change proposed is to execute an action in a JobQueue using an actionPolicy that can be defined for each action. So creating an action-handler for a button can be done using the 'Queued' policy which means it will be executed in a seperate thread (allowing swing-redraw updates) and automatically disabling the button while the code is running.
  A taste is here: http://uic.sf.net/tutorials/actions/action.jnlp

  Posted by: zander on May 11, 2004 at 01:46 PM

• Thoughts on a Swing wrapper...
  Lessons Learned From VB:

  1. It's easier to make something simple if you can limit it's scope.
  [VB simplier than C++, less flexible, fewer paradigms, less powerful and portable]

  2. Smaller scope is easier on toolmakers.
  [fewer requirements, less points of failure, more time to polish]

  3. Users can look elsewhere for more power, happy users are none-the-wiser. [if you really, really want to use pointers, you will find C++]

  4. Some ugliness can show thru. Just make it a syntax rule. (VB requires ()'s around param list sometimes, and sometimes doesn't allow them).

  Maybe Swing is the wrong candidate for a wrapper, because it attempts to address so many concerns that the target audience of an easier Swing just doesn't care about: design patterns, separation of concerns, MVC, cross-platform, backwards-compatiblity, etc. In a sense, Swing is very high-level. If you tried to make a simple wrapper around swing that was a. specific to one os, b. tied to one ide, c. with one easy way to do each task, you'd have VB.
  

  Posted by: d_bleyl on May 11, 2004 at 02:02 PM

• I feel your pain
  Basic table functionality is actually pretty straighforward in Swing.

  Movable columns are enabled by default. To DISABLE them, you need to do:

  jtable.getTableHeader().setReorderingAllowed(false);

  Everything you want to know about JTables can be found in Sun's tutorial on them at http://java.sun.com/docs/books/tutorial/uiswing/components/table.html

  There is sample code provided there that will enable sorting (with shift-clicking to sort in reverse order, and control-clicking to enable secondary sorting). You just wrap your table model in the TableSorter and everything else is taken care of for you. I've been using this code for years.

  Posted by: jonbodner on May 11, 2004 at 02:39 PM

• Agreed. But what's the answer?
  Swing is complicated and your points are quite right -- the API JavaDoc doesn't help anyone figure out the right path to a good Swing application, it only helps when you have the odd detail that you can't remember or didn't know about.

  What I'd like to see is a less-intense intro to Swing book or tutorial. Top 10 things every Swing developer should know. Explanation of the design and intended use of Swing. A couple small sample apps (nothing quite as big as SwingSet) of common things that Swing developers would need to do. That would be extremely helpful.

  I've played around with AWT and Swing in the early days before being converted to a J2EE developer, and am heading down a road leading to Swing clients, so such a book or tutorial would be extremely useful. Once I get started on anything new, I always hit the 'net. If there's a large base of "bad" examples and people recommending what are actually anti-patterns, then I'm in for a rough time sorting fact from fiction. Could the desktop community maybe collect a list of books, tutorials, and good example apps for display? And maybe set up a "black list" of popular books and resources that do Swing wrong?

  To finish up, what's the full question about Swing threading, and what is the correct answer? Is there a way to phrase it differently so you don't give away your interview question but can still educate the ignorant?

  Posted by: gerryg on May 11, 2004 at 02:45 PM

• most people learn quickly by example
  The question is whether that code belongs on the JavaDoc. IMHO, it doesnt.

  Posted by: jonathansimon on May 11, 2004 at 04:23 PM

• Not so much hard as different
  IMO, the issue isn't so much that Swing is hard, as that it is simply different than other component libraries. I came from a Delphi component writing background some years ago, and it took quite a while to really feel comfortable with the right way to do things. Case in point: Typically in Swing, subclassing a component is the *wrong* way to solve a problem - but most gui component libraries use inheritance as their extension mechanism. So it's the tool a developer coming in from another environment naturally heads for first.

  The point being that good Swing programming uses a different set of patterns than the ones developers from other languages are used to; and you bump into peculiarities of the hardware (color depth, fonts, etc.) a lot more easily.

  Regarding complexity, well, GUI programming is complex - or let me say, *good* GUI programming is complex. It is a different set and type of problems than those of server side programming - server side programs generally don't deal in heuristics much. You can get 80% of intuitiveness with plain, vanilla drag and drop programming. That last 20% of functionality, making it *really* intuitive is going end up being 80% of the work.

  Now, some of this can be encapsulated into higher level components - I don't see a need for a wrapper around Swing so much as more well written components that do complex things. For example, how many times has "dialog with two lists and an add and remove button" been written? It would be much nicer to call SomeFactory.makePanel(ListModel from, ListModel to, SomeDescriptorClass obj).

  But I think some of this reaction is simply that server side programming got a reputation as being difficult, sexy, whatever, and there's this expectation out there that GUI programming is comparitively easier. Which is simply not correct - writing a non trivial application in whatever environment is, well, non-trivial.

  Posted by: timboudreau on May 11, 2004 at 05:44 PM

• I feel your pain
  I wasn't saying it couldn't be done, I was just saying that it wasn't as simple as it really should be.

  Posted by: archangel on May 12, 2004 at 01:07 AM

• Not so much hard as different
  I've done the ui for several swing projects. I also know several people who have become swing specialists.

  I would say that if you don't want to subclass, you are going to have a hard time, because most of the models are *designed* so that you can replace them without too much trouble.

  One of the things I do to make life easier is to define classes where I group several related components together on a panel, with their own layout and behaviour etc, and then can treat them as a single object.

  Very much a lego approach, slap the building blocks together, then build bigger building blocks out of smaller buiding blocks... etc.

  Using the power of inheritance or composition in this way lets me make sweeping changes to the ui very quickly - and if one of my composition building blocks needs to be slightly different than all the others of that type... just subclass it!.

  A real world example: I inherited one project where all the labels were above the components they were associated with, and a whole lot more screens needed to be built, so I defined a LabelledComponentPanel to do this, and then in the constructor I would pass in the component and the string for the label. That 1/2hr worth of work then saved at least a week of development time (or more in VB, since you'd end up doing an enormous amount of aligning controls up and other fun twiddling which you get for free in Java (well, its only free if you have the right LayoutManager, but the layout managers cover a good 70-90% of what you want to do most of the time)). I think I ended up creating a second subclass to deal with a particular kind of component that didn't behave quite like the others, but that was no big deal.

  Posted by: rickcarson on May 12, 2004 at 02:01 AM

• Agreed. But what's the answer?
  I've done VB and Swing programming. I like to think my VB was pretty good, and I put a lot of effort into the uis.

  In VB, if someone makes a bad ui, people say "you made a bad ui".

  In Swing, if someone makes a bad ui, people say "swing sux".

  Stop blaming the language. Everything you can do in VB you can do in Swing, and a whole lot of stuff you can't do because its hidden away from you!

  Posted by: rickcarson on May 12, 2004 at 02:04 AM

• Thoughts on a Swing wrapper...
  See also my previous reply which ended up attached to the message one up instead of this one. And I've have gotten away with it if it wasn't for you pesky kids and your Java.Net!!

  Swing isn't high level. Swing gives you all the gory details which as a VB programmer you would occassionally liked to have been able to see. Swing is very low level, you have a lot of control over what happens and the way things look.

  I agree with your key point - a lot of effort goes into making VB do the simple things easily. If you do enough simple things fast enough, you can obscure the fact that it also makes the hard things impossible (and for the almost impossible, we have the Win32Api).

  Swing doesn't put any effort at all into making anything easy. Instead, the effort is in making the impossible things merely hard.

  Posted by: rickcarson on May 12, 2004 at 02:11 AM

• Swing is not finished enough.
  The listener/event model which Swing uses is really simple and easy to use.

  Anonymous inner classes were a bit strange (I started pre 1.02) when they first appeared in the language, and IDEs probably have a difficult time with them, but they're not hard.

  One project I inherited the chap before me had done what you suggested, and written his own threads to do event handling... (to make it 'go faster') which made the code a real pig to understand and modify, I ended up ripping out the vast majority of it, and slapping in standard boring Swing event handlers, and it sped the code up massivley.

  The only places we ended up using a separate thread was for things like when we kicked off Acrobat to do the printing, and that was only so that the menu option would disappear quicker and not look like it had 'hung'.

  Half of proper threading in a ui is to know when to use smoke and mirrors. I have a friend who is really good at cranking out maximum performance from his code. He occassionally would tell me that the users were complaining it was too slow, and he was thinking about writing some assembler... so I'd ask him what he was trying to do, and then I'd say something like "oh, just stick in a splash screen" or "kick that off in a separate thread". Every time he'd reply "but that will make it *slower*" and, of course, he'd be right. But then he'd get so much complaining that he'd try my suggestion just to prove me wrong... and he'd come back and tell me that "I did what you suggested and now the users think its really fast...".

  Managing the users perception and expectation is actually pretty easy, just go look at all the smoke and mirrors VB programmers have been using for years. :-)

  Posted by: rickcarson on May 12, 2004 at 02:24 AM

• most people learn quickly by example
  VB documentation was absolutely brilliant up (literally a decade or more ahead of anything comparable) to version 6, and then it all went so terribly badly wrong....

  On version greater than 5, the point where they munged all the doco for all their products together, I'd often just give up searching for ways to do things that I knew could be done, and I'd just reach out, twiddle the Win32Api to do what I wanted, and then carry on.

  It does give one a reputation for deep mastery of bad juju, but its not good for the soul.

  The disadvantage of the VB doco compared to the Java doco, is that if the VB doco was wrong, only trial and error would enable you to figure out what it actually did. Whereas with Java, if something doesn't work the way you think the doco is telling you it works, you can just 'lift up the hood' and see what its *really* doing.

  The Java documentation is pretty good. It's actually really hard to do documentation that is that good and that consistent, it requires serious effort.

  Posted by: rickcarson on May 12, 2004 at 02:33 AM

• How do you do threading in VB?
  You are dead on the money, except for:

  
  Their code looks so much like COM/C++/Win32 that they start coding in C++...

  My code did end up looking like a bunch of Win32Api calls... (It helps if your introduction to Windows is to be handed Petzold and told 'here, read this' (the person who did that later apologised and said he wouldn't have done anything like that to anyone else, but he figured I was the only person he knew that could handle it :-) ... a subtle way to get revenge for all my rules lawyering over the various boardgames we played I guess... :-)

  But... in my case I switched to Java. Like banging your head against the wall, it feels so good when you stop. :-)

  Posted by: rickcarson on May 12, 2004 at 02:41 AM

• How do you do threading in VB?
  Apologies for the double reply.

  I have a friend who solved the problem differently. When on a contract at a VB shop he wrote all his code in J++ and then bundled up his objects as ActiveX components.

  Everyone loved it, his components were much, much easier to use than everyone elses (because he *had* to design for reuse to get away with this :-) and they were a lot more robust (decent exception handling... goes a long way). The only problem was he was finished so much faster than everyone else that they kept badgering him how he had done it... I told him to hold out, but eventually he cracked and told them the secret, and they made him rewrite in VB so they'd be as bad as everyone elses. (NB: deployment and compatability was not an issue in this case, there was *no* good reason not to use J++)

  Posted by: rickcarson on May 12, 2004 at 02:49 AM

• Maybe some designe flaws ?
  I think the main problem with Swing is that it's quite complex to do simple things.
  I've seen complaints from people coming from VB dev:

  - They get crazy to have a correct layout. They keeps their heads bumped on the wall when they need to write a dialog box.
  Layout managers are quite poorly designed, the one really powerful is GridBagLayoutMgr and it's complexity is awesome.
  I haven't seen any Java GUI design tool allowing a "normal" developer to do easily dialog box layout.

  - The action model does not support threading. Right now, the easy thing to do in Swing is to listen to components events. Great, but you should not do that !
  You need to listen to event, then create a new thread and do your work in it. Why isn't it implemented by default in swing ?

  Moreover, in this worker thread you can modify UI directly (for example you can update a progress bar), but once again, Great, but you should not do that !. You need to update your U.I. in the swing thread ! Simply Awefull !

  My .02

  Gérard
  

  Posted by: gcollin on May 12, 2004 at 02:55 AM

• The real problem with Java GUIs...
  ... is that the IDE's *all* are awful.

  Everytime I pick up a Swing application thats been modified in house (and don't even talk to me about open source, lets just not go there), I just know there's going to be an enormous panel/frame class in which eveything else is defined, variable declarations are going to be all over the place... controls will have bad VBish default names (eg flowLayout223).

  Then if you refactor it, to make it all nice and neat, use a few subclasses for the common component associations, maybe treat each of your own sub panels as its own separate class with its own instantiation... the IDE now won't even display your application in design mode.

  With even moderate refactoring to make the code tidier the IDE's just give up!

  So you end up having to either test it by running it, or you have to basically memorise the whole of your gui model (a good argument for having only one person that does the gui), or you divide it up into little chunks and building lots and lots of 'mini apps' - which sounds like a good thing, but then you write a whole infrastructure just to decouple all the bits of the ui from the other bits of the ui, and the ui from your app.

  Now that may *sound* like a good thing, but its not. You end up with something like 20 classes per button, its just not worth it. (And no, your IDE still won't come to the party)

  Or... you could tie your application to your IDE, and design all your components so that they plug into your IDE... which again is an enormous investment (which might pay dividends in the long run, I've never tried it).

  The best way is to basically throw out or ignore the form building part of your IDE, which is a shame because then only experts will be able to do your Java uis. Contrast this with VB, where you could get the neophytes to 'paint by numbers' the basic interface stuff, and then experts could work on the 'hard bits'.

  In Java, the experts have to do the UI, and the neophytes end up doing the back end stuff...!!!

  My hat goes off to whoever made VB look the same(ish) in design mode and at runtime. Sure, they probably made some of the design decisions that meant you can't peek under the bonnet, but its an incredible achievement nonetheless.

  Posted by: rickcarson on May 12, 2004 at 03:10 AM

• The real problem with Java GUIs...
  >My hat goes off to whoever made VB look the same(ish) in
  >design mode and at runtime

  There's a dirty little secret there - as everyone crows about wanting "2 way editing", none of the windows gui builders have it. Deriving a design time UI by parsing code is an extremely hard problem (provably impossible in a stateful UI), one avoided entirely by VB, Delphi, etc., which are using windows resource files - so the static part of the GUI is completely declarative and always in a consistent format - so making the design time and run time UIs look the same is natural. Yes, you can hand code your entire windows GUI, but no GUI builder would choose that approach unless there were no alternative. The point being that Swing could use a similar standard format for this (bean persistence is not quite it) - 2 way editing is simply not a problem we should have ever tried to solve. *Standard* is the key here - no IDE vendor wants to require their users to ship some library of theirs to process proprietary form files, because users don't like that.

  Posted by: timboudreau on May 12, 2004 at 03:35 AM

• What about a Swing blueprint application?
  Hi,

  I think that one of the big missing things is a "Pet Store" like Swing application.

  Showing the way the things should be done and been a starting point for new commers.

  Cheers

  Posted by: jdavi on May 12, 2004 at 03:37 AM

• Swing was a victim of deployment and performance issues
  I disagree that the Swing API is too difficult. Sure, there are places where it could be easier to do things but once the API and its methodology is understood- look out. A developer can do amazing things with it

  Is that so?

  Then why noone has done anything usefull or interesting with Swing?

  Only IDEA comes to mind as a remotely usable Swing app.

  Any developer can understand the Threading issues in about 15 minutes by reading any of the good swing books and tutorials

  Yes. And after he understood them, he has to live with them. And all the other crap that comes with Swing.

  Only people starting out with Design Patterns are delighted with Swing. It's a contrived example of Design Patterns.

  Posted by: hejazzman on May 12, 2004 at 04:38 AM

• Swing is not finished enough.
  I think it's a combination of the java syntax and the complex design of Swing itself.

  I agree your UICompiler is great. QT Designer is the best open source GUI designer out there. Unfortunately it is not free on Windows, which most people still use.

  And things could still be made EVEN simpler eventually. For example, I have to scan through a difficult to read XML ui file to figure out the what is what. Wouldn't it be nice to be able to use YAML for a ui file too? Or else code event bindings from within QT Designer like you can for C++ apps?

  And for event binding, there is still the complexity of java's syntax and the extreme modularity of swing. What if we could use jython and simply say something like:
  listbox.bind(SELECT, self.onListSelect, THREADED) #fake constants that a swing wrapper would convert into action classes

  Finally, if Swing were open source we could make significant additions and simplifications ourselves. Right now it is just simpler to use pyuic with pyqt, or wxpython, instead of messing with Swing.

  Posted by: dug on May 12, 2004 at 07:58 AM

• Swing was a victim of deployment and performance issues
  'Then why noone has done anything usefull or interesting with Swing?'

  (God what an ignorant an meaningless flame-bait post; am I being a fool to reply?) There are many Swing apps frequently used every day, including open source (jedit), commercial (IDEA, JBuilder), and (as someone recently pointed out) lots of in-house apps that no one (oh - sorry 'noone' as you so ungrammatically put it) hears about. Jeez!

  Posted by: cornell on May 12, 2004 at 08:14 AM

• I feel your pain
  the primary pain with jtables is that it's hacky to get row headers just like column headers are. the best way I know is just to make a scrollpane and add JList with buttons at the left side of regular table.

  Posted by: tehvlon on May 12, 2004 at 09:29 AM

• Layout Managers...
  Ok... I cringe as I post this...

  I was just wondering what people thought of James Elliot's RelativeLayout Layout Manager?

  http://www.onjava.com/pub/a/onjava/2002/09/18/relativelayout.html

  I keep thinking I must be missing something... other than it's "non-standard".

  This Layout Manager really seems to be easy to use and powerful.

  Just curious if anyone else has tried it? Thoughts....

  thanks,

  John

  Posted by: johnchildress on May 12, 2004 at 09:57 AM

• Layout Managers...
  Hi John,

  I use RelativeLayout to layout pages for my framework JForm and I must say it's great!

  It's indeed easy to use and very powerfull.

  I can recommend it.

  Will
  author of JForm
  http://jform.coderight.nl
  

  Posted by: wlboluyt on May 12, 2004 at 10:27 AM

• Maybe some designe flaws ?

  Do you program in Java/Swing?
  too bad, you should not do that !

  If you don't understand Swing, you can't handle it and start complaining it's not working...

  Will

  Posted by: wlboluyt on May 12, 2004 at 10:34 AM

• Where to get it from.
  Swing isn't about to change. Programmers need to understand it as it is now. But how?

  I was asked last week where I would refer to for best practises in Java (not J2EE). I have to admit that I was stumped. I could list a few individual books that are good, but no general rule. There's obviously the Java source code, but that contains, for instance, 95 cases of double checked locking, mutable objects where immutable would have been much better and consistent inconsistency.

  Subjects such as threading in Swing doesn't fit nicely with method oriented JavaDoc. In my bookcase of technical books, not one is about Swing. No Swing book has ever looked worth buying. Far too many articles give bad advice. Where else would the average programmer look? Until the end of last year it seemed as if, give or take a few bugs, creating and showing components outside of the AWT thread was fine. Pretty much all non-applet examples called show/setVisible from the main thread. Look through the code (perhaps the best way to find out about Swing) and you'll see that the practise is unsafe.

  Posted by: tackline on May 12, 2004 at 11:00 AM

• Maybe some designe flaws ?
  You're right on the money there.

  Basically, it sounds like this would work well with the "swing wrapper" that so many people have clamored for.

  As for my personal swing experience, I can't say enough good things about its powerful feature set. However, this is after working for about a solid year building a very complex swing application, and going through many trials and tribulations with it.

  Here are my beginning swing best practices:
  1. Use a GUI editor to get design ideas, but don't actually use it in your final code. Code everything you plan to keep by hand for reusability and maintainability sake.
  2. Look at the source code. Have a bug somewhere that you can't figure out? Start going through the source and find out how exactly the Swing component that you're using works. Not only will this probably help you solve your bug, but it will give you great insights on how to customize components. This is how I learned how to build CellRenderers for Lists and Tables.
  3. Execute all listener code in new threads and explicitly make all gui calls within the SwingUtilities.invokeLater() method. This keeps your GUI responsive and improves code portability (i.e. if you move your code to methods that are not guaranteed to be called by the Swing Thread, using explicit SwingUtilities.invokeLater calls means they always will).

  The problems with these practices is that they tend to be time consuming and lead to the developer manually generating a lot of wrapper code (putting method logic into Runnable objects mostly). However, this investment is well worth the effort simply for the maintainability it provides.

  -Heath

  Posted by: heaththegreat on May 12, 2004 at 06:58 PM

• Swing is not finished enough.
  | The listener/event model which Swing uses is really simple and easy to use. Anonymous inner classes were
  | a bit strange []

  Ehm; I think you completely missed the point of this thread; using anonymous inner classes for event handling is easy, yes; but it is completely wrong for responsive UIs. Long running tasks should be delegated to a different thread, this is common knowledge. And as the initial poster of this blog said; people STILL are not getting it.
  Reading your post, I think you belong in that category...

  Posted by: zander on May 13, 2004 at 05:46 AM

• Swing is not finished enough.
  | For example, I have to scan through a difficult to read
  | XML ui file to figure out the what is what.

  Why would you want to do that??
  The whole point of the compiler is to produce ready made code from that file; you never have to read or edit it...

  
  | And for event binding, there is still the complexity of
  | java's syntax and the extreme modularity of swing.

  True; I'm always searching for ways to make it simpler and more accessive to the larger crowed. Since I got the introduction to Groovy I'm thinking of allowing people to code event handlers in that language..

  Posted by: zander on May 13, 2004 at 05:51 AM

• Where to get it from.
  For best practices in programming Java, http://www.javapractices.com/index.cjp is a good place to start--not super extensive, but covers most of the common cases that you run into.

  
  Patrick

  Posted by: pdoubleya on May 13, 2004 at 07:18 AM

• The GUI Builder
  In my experience the entirety of Swing's problem isn't necessarily Swing but the lack of a good GUI builder. Even the prevelent IDEs (if you accept their constraints) SUCK. Its easy to create a GUI builder that only does absolute positioning (like VB), but the constrained model is much more difficult to visualize.

  I recently found the start of a solution to this problem. Its not perfect but it does illustrate how good things can get if you take the road less traveled. Take a look at QT Designer (available on all linux distros... you can also get a free older version for Windows) and the UI Compiler for Java: http://uic.sourceforge.net/ . It took me about an hour to learn QT designer and then I was creating beutiful UIs that scaled perfectly on resize. And I was able to make them look exactly as I pictured them in my mind... no sacrifices for problems I didn't know how to code around in the Swing layout system.

  Really, this accelerated my Swing development like nothing else. Also, since the code emmitted by UICompiler assumes that you will be subclassing in order to do any work, it is free to completely obliterate the base class and regenerate it on demand... Just provide an Ant target that generates all of your UI base classes from the QT Designer .UI files and you're done. And the subclassing paradigm forces you into a little better MVC style than you get with the IDE bundled UI builders.

  It's no wonder that with tools like these that your average Unix/C++ GUI developer doesn't even want to think about touching Java.

  Posted by: tlaurenzo on May 13, 2004 at 07:24 AM

• Where to get it from.
  I haven't looked at the second edition, but the first edition was really good (not just a reprint of websites):
  Title: Swing
  Author: Matthew Robinson
  Publisher: Manning

  Posted by: tlaurenzo on May 13, 2004 at 07:28 AM

• Layout Managers...
  I have modified RelativeLayout to fix some of the things that I saw as flaws, and have been using that version in pretty much everything for over a year now. I think RelativeLayout is just as powerful as GridBag but it makes intuitive sense, even to a non-programmer. If you haven't tried using RelativeLayout, do yourself a favor and play with it--it's marvelous!

  Posted by: johnsogg on May 13, 2004 at 08:56 AM

• Layout Managers...
  Do you mind sharing what changes you have made? If not the source, then maybe just a short description?

  My e-mail address is jchildressNOSPAM@johnchildress.com

  thanks,

  John

  Posted by: johnchildress on May 13, 2004 at 10:51 AM

• The GUI Builder
  I fail to see how GUI builders are going to help programmers to get Swing threading.

  GUI builders are worthless when you have Swing anyway. Layout is the most trivial code anywhere in an application. Sketch the design on something flat, white and not too valuable, then it's a piece of cake just to rattle the code off. The odd helper can simplify things, but that's not mandatory.

  Posted by: tackline on May 13, 2004 at 07:08 PM

• javapractices.com
  I thought I'd check out what it says about Swing threads. In the first section it mentions that JComponent.invalidate and all add/remove listener methods are thread-safe. The code says otherwise.

  Posted by: tackline on May 13, 2004 at 07:08 PM

• Thoughts on a Swing wrapper...
  Sorry Rick, I was thinking of high-level in the sense
  that Swing has some design notions, such as MVC or heavy use of interfaces that I wouldn't expect to see in the low-level world. My mind immediately jumped to passing WM_XX messages around, and bit-twiddling, windows.h stuff.

  Posted by: d_bleyl on May 14, 2004 at 08:13 AM

• Layout Managers...
  Yes, I've used RelativeLayout. It works nicely.
  Here are a few tips to using it.

  1. Make a ConstantConstraint subclass that returns a fixed value:

  public class ConstantConstraint implements Constraint
  {
  int value;
  
  public ConstantConstraint(int value)
  {
  super();
  this.value = value;
  }

  static List cDummyDependencies = Collections.singletonList(new Attribute(SubxLayout.ROOT, Attr.LEFT));
  
  public List getDependencies()
  {
  return cDummyDependencies;
  }

  public int getValue(AttributeSource attributes)
  {
  return value;
  }
  }

  2. Make abbreviations of the somewhat verboce constants. See example in 3 below.

  3. Make a container that knows about RelativeLayout. Override the add method to take various numbers of contraints. So you can write code like this:

  cont.add(new JButton("Save"), "save-button",
  Attr.TOP, new RootCons(Attr.TOP),
  Attr.LEFT, new RootCons(Attr.LEFT),
  Attr.RIGHT, new RootCons(Attr.RIGHT));

  Posted by: dlyall on May 14, 2004 at 08:38 AM

• How do you do threading in VB?
  Haha! That's awesome. I never used J++ (except the reference for Jacob COM stuff). How hard-headed can someone be? If your work is better and faster, then you'd expect things to go the other way.

  Posted by: d_bleyl on May 14, 2004 at 08:47 AM

• Agreed. But what's the answer?
  Yeah, but sometimes in VB, if you made a bad UI, you'd just say 'yeah, it would've rocked, but you cheap b*strds wouldn't buy the Pro XYZ GUI Components so that's what you get!' Or 'If I didn't spend so much time rolling my own Table from the list control, I'd get it done faster!'

  In Swing, people just say a. Where are all the beans or b. I found one, but it costs more than the server for one license.

  Posted by: d_bleyl on May 14, 2004 at 08:55 AM

• Components and the blame-game
  Perhaps, Swing gets blamed because they're aren't as many 3rd-party component vendors to blame.

  Posted by: d_bleyl on May 14, 2004 at 09:01 AM

• Maybe some designe flaws ?
  You can't blame people for not understanding Swing as it's overly complicated.
  I know the reasons why Sun chose that level of complexity, but that doesn't make it OK for Swing to be so complex that most users just give up on it...

  Posted by: jwenting on May 17, 2004 at 12:00 AM

• Has anyone not used Netbeans?
  I primarily use Eclipse for Java, but when it comes to building GUIs, Netbeans is the best, and more importantly, simple and WYSIWYG. Better than IntelliJ IDEA. Better than Borland JBuilder X. You can DnD simple UIs, and it gives easy access to a lot of advanced Swing components and features.

  My advice: Try Netbeans 3.6 (and for more than 15 minutes). They already have example GUI code you can load up in the editor. And if you tried it before, try it again. The newest version is a lot faster than Netbeans used to be, and a lot better looking.

  Sure, it can be cumbersome doing UI in Netbeans and other code in Eclipse. But hey, if you actually take the time to separate UI code from program logic (which is the way to go anyway), this won't be a problem for you at all.

  Posted by: jmickelonis on May 18, 2004 at 12:57 AM

• If simple things are not simple, complex things are not possible ...
  One of the problem with Swing is, it does not grow on you, you have to grow to realize its power. And for that not many developers have the patience or inclination.

  For ex. I want a icon with text in a tree, I don't want to learn about some cell renderer in the process, or I want to show combo box in a table cell right away not some digging deeper, or I want to show a tooltip on tree node without breaking my head.

  For 80% of the time, I have always to do something simple, and I don't want to write a framework around Swing to do that, Swing should do that.

  Best thing for Swing would be to come up with set of simple classes, like SimpleTable, SimpleTree, SimpleEditor etc. which exposes the most used functionality at the expense of some speed and flexibility, for more sophisticated GUI one can still use the power.
  

  Posted by: bsoni on May 19, 2004 at 10:23 PM

• I don't understand the problem
  So, Swing is not the easiest thing in the world to grasp at first. Fine, I accept that, but I'm not sure I see the problem. As with anything else, if you use it you will get better at it. And if you don't grasp it at first there are plenty of tutorials and examples to help.
  Yes, it is true that Visual Studio makes coding easy, as long as you code the Micro$oft thinks is proper. Whenever I've used Visual Studio I spend as much time trying to figure out the code it generates as writing my own. Besides, and this is particularly true of C#, the applications you end up with are UGLY.
  Let's face it, blaming the IDE for the complexity of Swing is a cop-out. So there's no tool that lets you drag and drop a gui. So what? If the object is to learn Swing you don't want to drag and drop. You want to roll up your sleaves and get your hands dirty, otherwise you'll never learn how anything works, except the IDE. Is that programming? I think not.

  Posted by: sasdav on May 24, 2004 at 06:16 AM

• Swing is Easy
  Swing is not hard at all. I have been using it since the early betas and for production products. The key is reading the documentation. It is less complex than MSFT and far easier than IBM's SWT which is only easy because there are no options to choose from.

  Posted by: turbogeek on May 28, 2004 at 02:29 PM

• Swing is Easy
  Swing is easier than Microsoft SDK, but still much more work than VB

  Posted by: txie on July 16, 2004 at 08:28 PM

This work is licensed under a Creative Commons License.