<AWT Dev> [PATCH] Cleanup AWT peer interfaces

[Andrei V. Dmitriev]

Just built a fresh local repo with these changes and tried a bunch of 
Container, Component and Window-related reg-tests. They are just fine.

1) Just curious if the concrete peer code are supposed to be changed? 
Looking on XTextFieldPeer we may notice something like that:

     /**
      * DEPRECATED
      * @see java.awt.peer.TextFieldPeer
      */
     public Dimension preferredSize(int cols) {
         return getPreferredSize(cols);
     }

     public Dimension getPreferredSize() {
         return xtext.getPreferredSize();
     }

With this patch applied we aren't obliged anymore to support that stuff, 
right? Along with your new toolkit it's probably doesn't matter but does 
it look reasonable to cover that issue by some other CR? Or just add 
into the current patch if you are real hot? Predict that there are a lot 
of the code are supposed to be affected: 
src/windows/classes/sun/awt/windows/WxyzPeer.java, etc.
So the total number of files would be doubled. So be aware. :)

2)I don't take Motif toolkit into account. You are fixing that as well, 
- src/solaris/classes/sun/awt/motif/MComponentPeer.java.
You'll probably be suggested by the system to ignore that patch on the 
push stage. So be prepared.

Anyway, I'm fine with that patch. Approved.
Thanks,
   Andrei

Roman Kennke wrote:
> Also see the webrevs to this patch:
> 
> http://kennke.org/~roman/webrev/cleanpeers/webrev/
> 
> /Roman
> 
> Am Dienstag, den 16.09.2008, 12:11 +0200 schrieb Roman Kennke:
>> Sorry, I sent the wrong patch. Here's the correct one.
>>
>> /Roman
>>
>> Am Dienstag, den 16.09.2008, 11:02 +0200 schrieb Roman Kennke:
>>> Hello,
>>>
>>> The peer interfaces have a lot of duplicate methods, where one is
>>> deprecated and 'replaced' by a new one (for example, preferredSize() and
>>> getPreferredSize() ). I see that this makes sense for public API
>>> _classes_ to maintain backward compatibility, but it does _not_ make
>>> sense for interfaces. It only confuses those who have to implement those
>>> interfaces (which method should I implement? Which one is called, and
>>> which should call which?), and adds no value at all. Also: the new
>>> interface methods are not used (i.e. called by AWT) at all. As part of
>>> the Caciocavallo project I went through this stuff and removed the
>>> duplicates, leaving the new methods in the interfaces and made AWT call
>>> the new methods instead. There were also a couple of methods that are
>>> never called from AWT (like ComponentPeer.repaint() ), which I also
>>> removed (some of such methods are used, but only in the interface
>>> implementation, so it is not required to have them in the public
>>> interface). What do you think? Should this be merged into main JDK7?
>>>
>>> Cheers, Roman
>>>