Name: rm29839 Date: 05/01/98


Although bug #4026484 is officially closed, I also
consider the way deprecated methods where handled
a bug. I don't understand why having the deprecated
methods call the new methods would break backward
compatibility.

However, by having the new methods simply call the
deprecated ones, you introduce two anomolies into
the API:

1) performance

We all know that there is a performance cost, no
matter how small, to doing a method call. That's
the point of inlining finals. However, by
implementing deprecation the way it was done, you
introduce an additional performance penalty for
doing the right thing (using the new methods). I
would think you'd want to do the opposite.
Consider Component.resize(). In 1.0, it called
Component.reshape(), for a cost of two method
calls. Now, in 1.1 and 1.2, Component.setSize()
called Component.resize(), which has been fixed
to call the new method Component.setBounds(),
which then calls the deprecated method
Component.reshape(), for a total of 4 method calls.

2) Safe overriding

If I want to subclass a component and modify (or
inspect) any requests to move or resize it, I
would think that I would want to override
setBounds(). Unfortunately, this will not work,
because old code that will interact with my
component might call the deprecated reshape()
directly. Therefore, the only "safe" way for me
to handle this situation is to override reshape()
rather than setBounds(). Of course, now my new
component will stop working when the deprecated
methods finally disappear.

If there is some compatibility reason why the
deprecated methods can't be written to call the
new ones, please explain the reason in the
response to this bug report.
(Review ID: 28062)
======================================================================