Name: rm29839 Date: 04/27/98


Problem exists in 1.1.5 too.

The deprecated methods in the AWT classes should
not contain any code except for an invocation of
the non-deprecated replacement method. If I want
to override an inherited method like setVisible()
or setSize() or getMinimumSize() in a sub-class
of some Component, I run the risk that other code
(and especially older code) will call
show()/hide(), resize(), or minimumSize()
directly and my overridden method will be
bypassed.

An example of this is found in CardLayout which
makes direct calls to show() and hide() instead
of calling setVisible(true) and setVisible(false).
This is already reported in bug id 4049410, but
the problem is larger than simply correcting
the code in CardLayout. This same problem could
occur under other conditions.

In Component.java as of 1.2beta3, setSize() calls
resize():

public void resize(int width, int height) {
setBounds(x, y, width, height);
}
public void setSize(int width, int height) {
resize(width, height);
}

This should be changed so that the deprecated
method resize() will call setSize() instead:

public void resize(int width, int height) {
// setBounds(x, y, width, height);
setSize(width, height);
}
public void setSize(int width, int height) {
// resize(width, height);
setBounds(x, y, width, height);
}

Similarly, all code in the other deprecated
methods should be moved into the replacement
methods, and the deprecated methods should be
changed to simply invoke the new methods.

Now, if someone has overridden a method like
setVisible() in a sub-class of Component, old
calls to show() and hide() (like in CardLayout)
will indirectly call this new setVisible()
instead of ignoring it. Without these changes,
developers are forced to override all three of
setVisible(), show(), and hide() in their
subclasses and will be forced to use deprecated
methods.

Plus, as the code stands today, when the new
methods call the old (deprecated) methods, users
of the new methods are penalized with a slight
performance hit due to the second (indirect)
method call. I feel that any performance
degradation should fall on the users of the old
methods.

If these deprecated methods are to truely be
avoided, the source code of the core Java classes
needs to be updated. This will also prepare
for the ultimate removal of the deprecated
methods from the source.

---------------------
Below is a example of the recommended changes to
Component.java for setVisible, show, and hide:

public void setVisible(boolean b) {
// show(b);
if (b) {
showOld();
} else {
hideOld();
}
}

public void show(boolean b) {
setVisible(b);
// if (b) {
// show();
// } else {
// hide();
// }
}

public void show() {
setVisible(true);
}

public void hide() {
setVisible(false);
}

// Change old show() method to be private
// and rename it to be showOld():
// public void show() {
private void showOld() {
if (visible != true) {
synchronized (Component.LOCK) {
visible = true;
ComponentPeer peer = this.peer;
if (peer != null) {
peer.show();
if (peer instanceof java.awt.peer.LightweightPeer) {
repaint();
}
}
if (componentListener != null ||
(eventMask & AWTEvent.COMPONENT_EVENT_MASK) != 0) {
ComponentEvent e = new ComponentEvent(this,
ComponentEvent.COMPONENT_SHOWN);
Toolkit.getEventQueue().postEvent(e);
}
}
Container parent = this.parent;
if (parent != null) {
parent.invalidate();
}
}
}

// Change old hide() method to be private
// and rename it to be hideOld():
// public void hide() {
private void hideOld() {
if (visible != false) {
synchronized (Component.LOCK) {
visible = false;
ComponentPeer peer = this.peer;
if (peer != null) {
peer.hide();
if (peer instanceof java.awt.peer.LightweightPeer) {
repaint();
}
}
if (componentListener != null ||
(eventMask & AWTEvent.COMPONENT_EVENT_MASK) != 0) {
ComponentEvent e = new ComponentEvent(this,
ComponentEvent.COMPONENT_HIDDEN);
Toolkit.getEventQueue().postEvent(e);
}
}
Container parent = this.parent;
if (parent != null) {
parent.invalidate();
}
}
}
(Review ID: 27800)
======================================================================

jukka.tammisto@canada 1998-06-10

Description of another incident (33388).

The new methods in the awt classes that replaces deprecated methods is implemented by calling
the deprecated method, not the other way around (which would seem most reasonable). This gives
the penalty of an extra method call for using the new methods. An example from java.awt.component:

public void reshape(int x, int y, int width, int height) {
IS DEPRECATED, BUT THE IMPLEMENTATION IS STILL LOCATED HERE!

public void setBounds(int x, int y, int width, int height) {
   reshape(x, y, width, height);
}
IS THE PREFERRED METHOD, BUT INVOLVES AN EXTRA CALL TO reshape()!

This should be the other way around!!!!
And the same is the case for all other deprecated methods I've seen.

It is NOT tempting to use hours to replace deprecated methods in your old code when the result is a
slower executing program. This should be fixed by putting the implementation in the new, preferred
methods in the next release!

Harald Stendal