Alexander Potochkin's Blog

Why I don't use Swing hacks (in production code)

One of the big part of my work is fixing bugs in Swing but not all of them are to be fixed, some of them are closed because they describe the situations when someone uses Swing in undocumented way or trying to make Swing do something which it doesn't support.

My favourite example is so-called "Blocking GlassPane". If you file a bug with a description that you implemented a GlassPane to block your frame and it doesn't work, most likely it will immediately be closed as "not a bug". The reason is simple - glassPane is an internal feature of Swing and the library may use wherever it is necessary, for example currently we make it visible during resizing of internal frames to show a correct mouse cursor above any existing components.

Swing does it well if you just paint something on a GlassPane but when your GlassPane affects the processing of events it becomes what I call a "hack". There are many definitions what a "hack" is, either positive or negative, but I want to give a definition what I mean by this word

Hacks don't have to be alway good or bad. Some of them are creative and effective, some of them are just creative, but they are always different from recommended or well-known solutions.

Going back to Swing I want to mention the main feature of a code which uses hacks:

Hacks usually work well for a presentation or a blog entry, but very few of them work as good and stable as the core library code. When you think it is good enough, someone else finds a problem whith your code and when you fix it, another issue appears so when you fix the "last" problem you know enough to write another valid test case which will be broken with your code.

Even if you are pretty sure that your hack works well on your computer, there usually no guarantee that it doesn't fail for another OS or with some custom components which use similar hack.

The "Blocking GlassPane" is an interesting example because it is a well-known hack which has never worked well. It is easy to put a fancy animation to a GlassPane and add an empty MouseListener to block the MouseEvents but people tend to forget about KeyBoard events and it is usually possible to type something in a TextField under a Blocking GlassPane.

I already blogged about this issue and offered some solutions to make this hack more robust however a month ago I got a message from one of my readers, he told me that my improved Blocking Glasspane fails to block the menu accelerators, so if you use Alt+MenuShortCut the menu will appear.

Problems like that is a usual thing when you use hacks. The most straightforward fix for this particular problem would be to disable frame's JMenuBar before showing GlassPane and enabling it again when the GlassPane is gone, but don't ask me how give user a chance to interrupt the time-consuming operation which blocks his frame or how to ignore keyboards actions for other components.

During my work on JXTransformer I used any kind of hacks to make transformed components work as well as usual ones. I managed to make it work for unsigned applet however I used some fishy techniques which I can hardly recommend. And again I realized that it might work for the most usual cases but there will always be some cases when transformed components behave incorrectly and the only right fix is to change the Swing itself to support AffineTransform for JComponents.

After that I added a special note that JXTransformer has several known limitations and decided that my next project will use only recommended techniques which always work well.

That's the reason why I don't use any hacks in JXLayer component. When I started this project it was tempting to add some creative hacks to implement some unique features but I keep following the "no hacks rule" because I don't want to be blame if JXLayer wouldn't work for your project.

When hacks are welcome

If you think that I don't use hacks at all, it's not true. There are some situations where hacks (even the dirty ones) are welcome, I am talking about testing and debugging. Let's say you need to find a cause of a bug, and in this case all means which may help are good (until they are not a part of production code).

On SwingHelper project you can find a CheckThreadViolationRepaintManager which helps finding a Event Dispatch Thread violation in Swing applications as well as EventDispatchThreadHangMonitor to catch time-consuming tasks on Event Dispatch Thread.
I would hardly use custom RepaintManager or EventQueue for my components, but they work very well when it comes to debugging.

Testing is a similar story, when I have a choice between a manual regression test with no hacks and automated one with hacks, I always choose the last one, just because manual tests don't have much sense

Conclusion

I am a realist and I know that unfortunately it is almost impossible to make a big project without any hacks. The only recommendation I can give for this matter is do not use hacks just because you know them, try to follow the documented patterns as often as possible and you code will be more reliable

To be continued...

Comments

• What's the well-known solution for the case where the glasspane intercepts events?

  Posted by: ronaldtm on September 27, 2007 at 10:47 AM

• Hello ronaldtm

  Google gives the following links for "blocking glasspane "
  One
  ,
  Two,
  Three,
  Four, you can find more if you need

  
  You may also find additional information here

  Thanks
  alexp
  

  Posted by: alexfromsun on September 27, 2007 at 11:03 AM

• Reality is that even if you should blame the Swing team your're likely run out if business waiting for the bug to get fixed. This is why it's inevitable to have hacks. Thanks to the original Swing designers it's so flexible.

  Posted by: kirillk on September 27, 2007 at 11:36 AM

• Alex,
  Thank you for this post. I have used a glass pane for years to block a user from a long running task. I never noticed the keyboard accelerators still worked. I do agree that its best not to block user input but sometimes it is needed. Putting up a modal dialog just makes it so the user is blocked and cannot move the application (on windows). So its not really a good option. But I see why you say its the only safe way. (I put a cancel button on my glass pane)

  However, this blog post is symptomatic of a larger problem at Sun.
  You have different groups recommending methods that are debunked by other groups. This is a prime example. Swing Hacks is a published book from Sun employees. The rank and file swing programmers would take this as a recommendation.
  Perhaps a little peer review and communication would be in order.

  Posted by: brianaracnetcom on September 27, 2007 at 11:45 AM

• Only one Sun employee co-wrote Swing Hacks, Joshua Marinacci. And he wasn't at Sun when he started the book :p (I also contributed some of the hackiest hacks in this book - namely the -Dswing.aatext=true - but went at Sun afterwards :))

  Posted by: gfx on September 27, 2007 at 03:27 PM

• Hello Romain
  Thanks for your comment

  To Brianaracnetcom:
  As you can see it is hardly possible to say that the book you are talking about is the official Swing team recommendations
  Learing hacks is a good way to understand Swing guts
  but they are not the recommended way to go

  To Kirillk
  If hacks are inevitable and you fully understand how they work
  and which problems may appear, I am fine with that

  Thanks
  alexp

  Posted by: alexfromsun on September 28, 2007 at 10:06 AM

• Alex,
  I stand corrected on the book authors. I know Josh works at Sun, I did not know the timing. And BTW, I think swing hacks is a fun book.
  But I still assert there is a communications vacuum.
  When I read about a hack and then see it over and over again in demos at Java One, I have to think its considered a good idea.
  But that one hack aside (Which is pretty), there is a general gap of best practices and conflicting information from Sun. Part of this is unavoidable due to the openness of Java. Some of this might be solved by the Swing Framework, which I am not up to date on.
  Take the communication gap comment for what it is, an observation from a loyal swing user that is outside of Sun.
  

  Posted by: brianaracnetcom on September 28, 2007 at 12:38 PM

• The problem with the "Swing Hacks" book is that it contains solutions in search for problems. And that is just the wrong motivation to add a hack to production code.

  There are other, good motivations to add hacks to production code. Let's start with a better definition of the word hack:

  A creative circumvention of a limitation

  And unfortunately Swing has many limitations which hurt in the real world. If your customer insists that you make something happen "or else ..." you have a very good motivation for a hack. I do not agree that a programmer has to understand all implications of a hack. Swing is such a complex system, itself full of ugly hacks, bugs, and badly documented, that this is just not feasible.

  When it comes to Swing then part of the problem is not only that Swing is so limited, but also that the limitations don't get fixed. This is an attitude problem at Sun. Sun lacks the understanding and imagination of what is needed on the desktop. Many Sun people still seem to live in SunView (ups, I am showing my age here) lala-land. Sun thinks it's always right.

  Sun has totally failed to establish a best-practice for Swing coding. The examples that ship with the JDK are some of the worst Swing code. What is even worse, while Sun employees were busy writing shiny conference demos, no one at Sun could be arsed to clean up the JDK example mess during the last ten years. This is not an isolated case. The Swing tutorial examples are equally bad. They can't even be bothered to use JavaDoc for documentation and typically demonstrate badly structured code for badly structured GUIs.

  Sun also has fragmented and hidden GUI information in unbelievable ways. For example, try to find a single page listing all Swing system properties. Good luck. In general, some Swing information comes with the JDK. Some can be found in the TSC (which is on life support). Others on ominous pages like JDCTechTips, Almanac (blech!), Code samples, Online Training article, Java.net articles, multi-media samples, technical articles, 2D examples in four places (did you know Sun has a half-finished Postscript Interpreter in Java http://java.sun.com/products/java-media/2D/samples/postscript/PostscriptDemo.zip?). Then there are dev.java.net examples, JDC, SDN, whatnot. I have probably forgot another ten places where Sun hides Swing, 2D, media, GUI or desktop information.

  No one at Sun seems to coordinate the stuff. Instead everyone at Sun seems to run the his own show, trying to establish an own kingdom. For deities sake, coordinate your documentation and example in one single place. And make sure they demonstrate best practice.
  

  Posted by: ewin on September 28, 2007 at 02:58 PM

• I agree, hacks are bad in production code. You only have to hark back to the glorious days of the Commodore Amiga (remember those? Bleeding edge technology in their day, but a dead dodo now!). When the newer amigas were released the frequently hacked together games of the day refused to run on the newer machines, This proves that hacks are bad don't you think?

  Posted by: badmofo on September 28, 2007 at 04:11 PM

• To brianaracnetcom
  I agree that "Swing hacks" is a fun book,
  my idea is that hacks and best practices are different things

  
  To ewin
  Some of your statement are too strong,
  but I must say that I mostly agree with you
  I have no excuses,
  but I am doing my best to make best practices possible and make hacks unnecessary

  To badmofo
  Hacks actually are not always bad,
  If you undrestand how does it work you gain more experience
  which you can apply later
  The ideal solution would be to quickly invent recommeded solutions
  for all use cases which require hacks

  Thanks
  alexp

  Posted by: alexfromsun on October 01, 2007 at 03:40 AM

• Alex, are they going to let you change JComponents to support your work on JXTransformer?

  Posted by: dwalend on October 02, 2007 at 07:24 PM

• Hello dwalend

  My colleagues are working on aspecial component for the JavaFX project which will probably (it's a secret :-)) allow to transform Swing components

  Thanks
  alexp

  Posted by: alexfromsun on October 03, 2007 at 03:50 AM

• That'd be huge. Thanks.

  Posted by: dwalend on October 03, 2007 at 07:49 AM

• When the Swing tutorial itself says,

  
  When the glass pane is visible, it blocks all input events from reaching the components in the content pane.

  I think it is a fairly easy step from that to trying to use it to block input events.

  Posted by: jayds on October 03, 2007 at 01:23 PM

• Hello jayds

  Thanks for the pointer,
  Swing tututorial is being updated
  I'll ask tech writers to fix glassPane's chapter

  Thanks again
  alexp

  Posted by: alexfromsun on October 04, 2007 at 05:59 AM

This work is licensed under a Creative Commons License.