Placing components on each other

by Dr. Heinz M. Kabutz

Welcome to the 41th (or is it 41st?) edition of The Java(tm) Specialists' Newsletter, sent to 2690 Java experts in
over 74 countries. This newsletter is for those that want to be
able to stump their interviewer when they get tough Java
interview questions. e.g. "Will this compile?"

Normal Java programmers would answer: "No.", but ardent followers
of this newsletter will answer: "Have the JDK classes been
modified in any way? With an unmodified JDK this would not
compile, but if you made String non-final it would compile.
You would also have to make it non-final in the runtime;
otherwise you would get a runtime error. However, since JDK 1.3,
it has not been necessary to cache the hash code in a subclass of
String as that is done already inside String." This will so
amaze the interviewer that you will have that hot job doing Java
development in no time!

Right now, I should've been in Mauritius presenting my Java
course, and next week would've been my Design Patterns course.
Of all the obstacles that courses face, this time we faced a
French-style bureaucracy in Mauritius :-( Everything was
organised: we had enough attendants, the hotel was booked, my
flight was booked. However, we could not get the correct
government approval in time, so I will have to wait a bit longer
before I can go "teach in the sun" again. In the meantime I'm
trying to learn that strange "sport" that all the sales people
play - golf. (OK, I admit - I've been playing golf instead of
writing newsletters *blush*)

Placing components on each other

Two weeks ago, I was presenting my course Design Patterns -
The Timeless Way of Coding to some experienced Java
developers, and we spent quite a bit of time arguing about the
Composite pattern. To refresh your memory, the book
on OO Design Patterns by Erich Gamma et al, contains the
following classes in the structure section on Composite:

Hoping to have whet your appetite, I will not pursue that
discussion further here, but instead jump over to the JDK. A few
years ago, I was looking at the Composite pattern and comparing
it to the java.awt.Component. I found it
interesting that java.awt.Component did not contain the
add() and remove() methods, those were
contained in the subclass java.awt.Container.
However, when I looked at javax.swing.JComponent I
noticed that it extended java.awt.Container and
therefore contained the methods add() and
remove().

The big question is: Why? Was it done like this because
Java does not have multiple inheritance or was it done to more
closely follow the Composite pattern? My bet is on
multiple inheritance being the reason, but if you have reliable
information (not speculation) I'd love to hear from you.

So, how do you put this to use?

Multi-lined button

Say for example you want to have a JButton with multiple lines
of labels on it. One way is to use HTML text, but then the
default font is different to the normal JButton font. An answer
is to stick a few JLabels on top of a JButton (remember that
JButton extends AbstractButton extends JComponent extends
Container). You can make such a button by doing the following:

This will produce a button with several lines on it. The problem
with that example is that the focus of the button is not shown.

CheckBox on a Button

What we can also do is put a JCheckBox (or any Component for that
matter) on top of a JButton. This can be used to make really
confusing user interfaces. Please don't actually do this, I'm
just illustrating something here...

Well, there you go. I have not found any IDE's which support
this functionality directly, and I would be surprised if there
was such an IDE. You should not really add complex components to
each other, as it will confuse your users. Imagine trying to
write a user manual for buttons containing trees and check boxes!

This was again one of the funnest newsletters to write, I'm
looking forward to your feedback :-)

Oracle and Java are registered trademarks of Oracle and/or its
affiliates. Other names may be trademarks of their respective
owners. JavaSpecialists.eu is not connected to Oracle, Inc.
and is not sponsored by Oracle, Inc.