Hi Dmitri and Oleg, > > I understand than you do not want to add questionable code in 2D, > > but I do not like the idea to make this by adding questionable code > > to Swing. So before falliwing back to hack I'd suggest to thinkabout > > I'm not sure what you mean by "adding questionable code > to Swing" - the code was already there. Now instead of > directly calling sun internal API it will call a better > defined internal API.
Yeah, I agree. > > possible API, otherwise we have a good chance to keep this hack > > in Swing code forever :( > > Swing is part of the platform, and will always have to > use some APIs in the implementation which are not available > to external developers. > > I don't see a problem with that. In this particular case > I really don't see any benefit in exposing this very > platform-specific API to the developers. Yeah. It looks like most (all?) Sun-specific code is in SwingUtilities2 anyway, so this is more or less the porting interface for Swing for people who really need to port OpenJDK Swing to a different JDK. If it is a goal to support that, it might make sense to find all remaining uses of Sun-specific code in Swing and refactor that to also use SwingUtilities2. Or even better, create a separate interface and factory for implementations of that interface that would be provided by the developer who ports Swing. But that seems a little over the top right now. I also suggest to get the original patch through. /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-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Geschäftsführer: Dr. James J. Hunt
