<AWT Dev> java.awt.peer work

[Roman Kennke]

Hi Phil,
> > [1] This is really a little weird. There are new methods (for example,
> > getPreferredSize() instead of preferredSize()), but the old methods are
> > used everywhere, so the new ones could just as well be removed. OTOH, I
> > feel that the new ones should be used and the old ones removed. Having
> > both in the interface doesn't help anybody, not for backwards
> > compatibility and not for developing new peers.
> 
> Its not uncommon in the JDK to see cases where what is used is the old
> method, and also for the new method to delegate to the old one.
> The usual reason for this is because existing code may have
> sub-classed and overridden those methods. If we didn't call
> them any more that code might break as it expected to be called.
> Border-line stuff I know, since except in somewhat rare cases,
> none of which I could point you to offhand, say when a method
> is called by the JDK.

I think the usual pattern is to leave the implementation in the
deprecated method, and let the new one call the old one. All other code
should call the new method (which delegates to the old one), this
ensures maximum backwards compatibility. The situation is a little
different for interfaces like the peers though, because we are not
talking about subclassing but about implementing, which is slightly
different. As it is now, we force implementers to implement both, the
old and the new, and the implementer doesn't really know which one is
called and how is the correct way to handle this. OTOH, the new
interface methods are there, but they are never called by AWT, so they
really are useless. I see that the implementations are made so that the
old methods call the new ones, but they could do just the same without
having the new methods in the interface (it's an implementation detail).

> I don't know for sure if that's really the situation you are
> seeing here, but if it is then, if someone has taken the care
> to preserve compatibility then its for a reason, in which case
> I'd recommend against change for the sake of change.

See above. I don't think this helps compatibility in any way and only
muddies up the interface and makes implementing it harder.

> > I know that java.awt.peer is a little special, as it is in the public
> > namespace but not publicly documented. What are the constraints on
> > changing these interfaces and docs? If it's not feasible anyway, I
> > probably better don't touch it at all. What is your optinion?
> 
> We are schizophrenic about this. Love to remove them, but nervous
> to do so.

My guess is that there are no external implementations of this out there
anyway, because implementing just that doesn't work right now, otherwise
I wouldn't have started this project :-) The only external toolkit
implementations that I know are fbtoolkit (which is now an OpenJDK
project, and patches the AWT and Swing classes in order to work
somewhat) and the GNU Classpath toolkits, which are implemented against
a slightly different (and cleaner) set of interfaces in java.awt.peer.

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt