Question

I’m a bit confused by the logic that’s been used to arrive at the current API for addLayoutComponent().

There’s two methods, one that takes a string and a component, and the other that takes an object and a component (but fails at runtime unless that object is a string.)

However, the one deprecated is the one that takes the string, not the one that takes the object. In my mind this is the wrong way around – why not keep the typesafe method that takes a string and deprecate the other?

And following on from this, is it better to, in this case, use the deprecated method and suppress the warning when it comes with the type safe guarantee?

Answer 1

I believe it is due to backward compatibility and the new methods introduced by LayoutManager2.

Originally all constraints for components were encoded as strings, "CENTER", "EAST", and so on. For a CardLayout it made sense to use these strings for names, such as "SETTINGS_CARD", "MAIN_CARD" etc.

In came LayoutManager2 which was a rework of LayoutManager. In this second version, they had realized that they wanted to allow for other types of constraints too, such as GridBagConstraints etc.

So, what CardLayout does is that it says, “Ok, fine, I’ll go with these new fancy methods, but I’ll still rely on strings because I don’t need anything else”.

Since the String version then became superflous, they chose to deprecate it. (That would be my guess at least.)

And following on from this, is it better to, in this case, use the deprecated method and suppress the warning when it comes with the type safe guarantee?

Using deprecated methods is in my opinion, be equal to say “I know better than the Sun/Oracle API architects.”. In other words, I would stay away from deprecated methods. (Besides other programmers will wonder why there’s a @SupressWarning in your code.)