classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch: fix handling of AWT alias methods


From: Ingo Prötel
Subject: Re: Patch: fix handling of AWT alias methods
Date: Tue, 03 Feb 2004 07:55:31 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

Hi,

this is a very nice explanation of the whole issue. Is there a place where we could put this on the website? I think it would be nice for people joining classpath to find documentation why we have to do it this roundabout way.

Ingo

Thomas Fitzsimmons wrote:
Hello,

This patch fixes the way we handle "alias" methods in the AWT, where a
public or protected method has been deprecated in favour of a new one
that has the same function but a different name.  Sun does this a fair
amount to fix cases where the original method's name did not follow
their naming conventions.

Unfortunately, this practise complicates class library code that calls
these aliased methods.  Library code must still call the deprecated
method so that old client code that overrides it continues to work.  But
library code must also call the new version, because new code is
expected to override the new method.

The correct way to handle this (and the way Sun does it) may seem
counterintuitive because it means that new code is less efficient than
old code: the new method must call the deprecated method, and throughout
the library code calls to the old method must be replaced with calls to
the new one.

Take the example of a newly-written container laying out a component and
wanting to know its preferred size.  The Component class has a
deprecated preferredSize method and a new method, getPreferredSize. Assume that the container is laying out an old component that overrides
preferredSize and a new component that overrides getPreferredSize.  If
the container calls getPreferredSize and the default implementation of
getPreferredSize calls preferredSize, then the old component will have
its preferredSize method called and new code will have its
getPreferredSize method called.

Even using this calling scheme, an old component may still be laid out
improperly if it implements a method, getPreferredSize, that has the
same signature as the new Component.getPreferredSize.  But that is a
general problem -- adding new public or protected methods to a
widely-used class that calls those methods internally is risky, because
existing client code may have already declared methods with the same
signature.

The solution may still seem counterintuitive -- why not have the
deprecated method call the new method, then have the library always call
the old method.  One problem with that, using the preferred size example
again, is that new containers, which will use the non-deprecated
getPreferredSize, will not get the preferred size of old components.

Jeroen Frijters provides a good explanation of the problem in his IKVM
web log [1].

Comments?

Tom

[1] GridBagLayout and more AWT, 
http://weblog.ikvm.net/commentview.aspx?guid=8B14C003-E16A-4E99-A52E-AD776CBB8CBF

2004-02-02  Thomas Fitzsimmons  <address@hidden>
[Patch was here ...]


--
Ingo Prötel                                          address@hidden
aicas GmbH                                        http://www.aicas.com
Haid-und-Neu-Str. 18                        phone   +49 721 663 968-32
76131 Karlsruhe                             fax     +49 721 663 968-93
Germany




reply via email to

[Prev in Thread] Current Thread [Next in Thread]