Andrew Haley <aph <at> redhat.com> writes: > > No, I don't mean that. I mean that if we change this behaviour today, > we can't guarantee that someone won't chnage it back tomorrow. > > So, use this as a temporary hack if you must, but prepare to be > disappointed.
So are you saying you'd oppose the idea of adding a Mauve test to verify this behavior, on the grounds that it's only for RI-compatibility rather than spec-compatibility? There are a LOT of Mauve tests, as I understand it, which test things that are completely unspecified other than by the RI's behavior. Swing, as a whole, isn't even close to specified enough to be independently implementable without that kind of testing. Sun themselves have a WONTFIX bug in their BTS saying so, so I'm not saying anything controversial here. IMHO the way to go here would be to recognize that this behavior is unspecified, but still put in a Mauve test for it so it doesn't regress, and try to work with Sun (in the new era of cooperation we now live in) to get it specified in future. Much as we might want to, we simply can't reasonably expect that people won't continue to introduce bugs like this, leaving other people in the situation of being unable to run things on Classpath. Seems to me that if we can get Sun to spell this out in the specification, we can have our cake and eat it too... Stuart.
