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
