Re: RFC: fix for Mauve test javax/swing/Border/TitledBorder/constructors.java

[Pavel Tisnovsky <ptisnovs@redhat.com>]

Dr Andrew John Hughes wrote:
> On 17:33 Fri 02 Sep     , Pavel Tisnovsky wrote:
>> Greetings,
>>
>> here's fix for another Mauve test. In the test
>> "javax/swing/Border/TitledBorder/constructors.java" the position of the title in
>> the border should be compared with the constant TitledBorder.DEFAULT_POSITION,
>> not with TitledBorder.TOP, at least in cases when following constructors are used:
>>
>> TitledBorder(Border border)
>> TitledBorder(Border border, String title)
>> TitledBorder(String title)
>>
>> (there exist three other constructors where title position can be explicitly
>> specified, but the fix changes only test cases which use the previous three
>> constructors).
>>
> 
> Can you explain why and note whether this affects current test results?
> 

Hi Andrew,

well, I've gone deeper into this issue and it seems, that GNU Classpath and
OpenJDK have quite different behaviour, but both are AFAIK correct due to
imprecise specification. When one of the following constructors are used to
create TitledBorder:

TitledBorder(Border border)
TitledBorder(Border border, String title)
TitledBorder(String title)

the text position is considered as DEFAULT_POSITION which * is equals * to TOP.
The only difference between GNU Classpath / OpenJDK is that GNU Classpath
explicitly sets text position to TOP in the constructor's body:

public TitledBorder(String title)
{
     this(/* border */ null, title, LEADING, TOP, /* titleFont */ null, /*
titleColor */ null);
}

but OpenJDK still stores DEFAULT_POSITION in following types of code:

switch (position) {
   case TOP:
   case DEFAULT:
       the same code block for TOP & DEFAULT

(the same pattern are used for text justification, ie for constants LEFT and
DEFAULT_JUSTIFICATION).

This means that TitledBorder("title").getTitlePosition()==TitledBorder.TOP on
GNU Classpath but
TitledBorder("title").getTitlePosition()==TitledBorder.DEFAULT_POSITION on
OpenJDK and proprietary JDKs too.

So it's IMHO better to change the test to check for both possibilities.

Pavel