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?

Ibby

I think you've done a good job phrasing your question in a constructive way. I hope it doesn't get closed. – Strike

Thanks for that - I deliberately tried to make it a constructive question, and am glad to get some good feedback. – Ibby

"but I only load and display the panels as they are actually required." Lazy instantiation can be used with CardLayout as well, and it supports 1000s of panels. – Brendis

Thanks @AndrewThompson, I wasn't sure if that was supported with CardLayout, so was kinda throwing that in there to get some verification whether it did/didn't support such an activity. – Ibby

@WATTOStudios Please don't approve suggested edits like this. If needed, refer to this meta post for details. – Fenugreek

Apologies for that, I do remember that post, unfortunately I was reviewing on my mobile and the wrong button was pressed. I know there were a few of these, but am glad it requires multiple people for the final verdict. I really should post on Meta about a mobile-friendly review page, or an undo button. – Ibby

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.

Inductive

Thanks for the great response, I had a gut feeling about some of these points, and it presents a number of good cases for using CardLayout. – Ibby

Related example may be found here and here. – Belindabelisarius

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?

Hurdygurdy

This raises a few good points too, thanks for your feedback. I can certainly understand that it would help to provide some assurance against failures. In regards to reinventing the wheel, I guess it never occurred to me that CardLayout would be suitable for my purposes, and I do a fair amount of tinkering at the low level of Java so it wasn't really a big leap for me to use the lower-level add()/remove() options. Thanks for the good points! – Ibby