What's so special about CardLayout vs manual adding/removal of JPanels?

Question

There have been many times on StackOverflow where a user asks a question like this...

I have a main JPanel that contains a child JPanel. When the user clicks a button, the child JPanel should change to a different JPanel. How can I achieve this.

More often than not, the user has actually tried to implement this problem, but can't get it working.

Whenever I answer this question, I tell them to do something like this (put simply)...

JPanel myFrame = new JPanel();
myFrame.remove(oldPanel);
myFrame.add(newPanel);

I see this as quite a legitimate answer, and I personally have used this in many of my own Java projects without problem. However, I always get downvotes for my answer, and everyone just says "Use a CardLayout".

So my question is, why is everyone so fascinated with CardLayout, to the point where my answer deserves a downvote? Why should I choose to use a CardLayout rather than adding/removing panels using my code above?

As a further question, would you still be suggesting CardLayout for interfaces that have dynamic JPanels. For example, most of my programs implement a custom plugin framework where there could be many hundreds of JPanels, but I only load and display the panels as they are actually required. For the normal use of the program, most of the panels would never actually be loaded or required. For this type of scenario, would my coding approach be the best solution, as I understand that CardLayout would require me to actually create all of the JPanels even though most will never be used?

Answer 1

• With CardLayout, it's easier to have loose coupling (though not impossible with roll your own)
• With CardLayout, the preferredSize of the card-holder is that of the largest card it holds.
• CardLayout is harder to fark-up, and allows almost trivial contiguous component swapping its next() and prev() methods.
• You can easily associate the desired component with a constant -- no need to have to create a Map<String, Component> for this purpose as it's already there for you. I've not infrequently used enums for this.
• No need to remember to call repaint() and revalidate() when swapping components.
• It's built for and allows for easy re-use of components.

I can't explain the reason for a down-vote though, unless they're upset you didn't mention the need to remember to call repaint() and revalidate() when swapping components. You'll have to ask the down-voter if they are brave enough to respond.

Answer 2

CardLayout has been thoroughly tested and proven to work. It correctly acquires the component-tree lock and performs component validation in order to ensure that nothing can go wrong. Your solution, while it may work most of the time, will fail under certain circumstances.

This all boils to reinventing the wheel: Why would you want to when such a time-tested class is already available?