-
Bug
-
Resolution: Fixed
-
P3
-
1.4.0
-
beta2
-
sparc
-
solaris_2.6
Name: acR10002 Date: 04/16/2001
The current spec for javax.swing.SizeSequence.setSize(int index, int size) says:
--------------------------------------------------------
public void setSize(int index,
int size)
Sets the size of the specified entry.
Parameters:
index - the index corresponding to the entry
size - the size of the entry
--------------------------------------------------------
It is not clear from this spec what is the expected behavior if index is
out of range, i.e. doesn't refer to any of the entries
(index<0 or index > getSizes().length).
Current implementation does nothing if index >= number of entries
and adds the size to the first entry if index < 0. Below is an example:
------------ Test.java --------------
import javax.swing.SizeSequence;
public class Test {
public static void main(String argv[]) {
int[] sizes = {10, 20, 30};
SizeSequence ss = new SizeSequence();
ss.setSizes(sizes);
System.out.println("initially:" + printSizeSequence(ss));
ss.setSize(-1, 999);
System.out.println("after setSize(-1, 999):" + printSizeSequence(ss));
ss.setSize(4, 999);
System.out.println("after setSize(4, 999):" + printSizeSequence(ss));
}
static String printSizeSequence(SizeSequence ss) {
String result = "";
for (int i=0; i<ss.getSizes().length; i++) {
result += " " + ss.getSize(i);
}
return result;
}
}
--------------------------------------
Output:
--------------------------
--> java -version
java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b58)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b58, mixed mode)
--> java Test
initially: 10 20 30
after setSize(-1, 999): 1009 20 30
after setSize(4, 999): 1009 20 30
--------------------------
This behavior is not obvious and needs to be documented if it is correct.
If the current behavior is wrong, then both the implementation and spec
should be fixed.
Also, the spec for getSize(int index) should document what is the expected
result if index is out of range. Current implementation just returns 0 in
this case.
Please note: this bug is not a duplicate of 4273397, the issue described
here is more general.
======================================================================