The following test shows that BasicFileChooserUI uses the JFileChooser
parameter in this particular case.
=== cut ===
import javax.swing.JFileChooser;
import javax.swing.plaf.basic.BasicFileChooserUI;
public class Harmony2895Test {
static private class TestFileChooser1 extends JFileChooser {
public int getApproveButtonMnemonic() {
System.err.println("TestFileCooser1");
return super.getApproveButtonMnemonic();
}
}
static private class TestFileChooser2 extends JFileChooser {
public int getApproveButtonMnemonic() {
System.err.println("TestFileCooser2");
return super.getApproveButtonMnemonic();
}
}
public static void main(String argv[]) {
BasicFileChooserUI bfc = new BasicFileChooserUI(new TestFileChooser1());
bfc.getApproveButtonMnemonic(new TestFileChooser2());
}
}
=== cut ===
It means that we should rewrite getApproveButtonMnemonic method or
treat it as non-bug-diff.
Thoughts?
SY, Alexey
2007/3/2, Alexey Petrenko <[EMAIL PROTECTED]>:
Guys,
here is an incompatibility described in HARMONY-2985:
=== cut ===
javax.swing.plaf.basic.BasicFileChooserUI.getApproveButtonMnemonic(null)
does not throw unspecified NPE
There is no mention of any exception in the specification. But RI
throws unspecified NPE for getApproveButtonMnemonic(null) while
Harmony does not.
Test case to reproduce, that passes on RI and fails on Harmony:
----------- test.java ----------------
import javax.swing.JFileChooser;
import javax.swing.plaf.basic.BasicFileChooserUI;
import junit.framework.TestCase;
import junit.textui.TestRunner;
public class test extends TestCase {
public static void main(String args[]) {
TestRunner.run(test.class);
}
public void testRun() {
try {
BasicFileChooserUI cb = new BasicFileChooserUI(new JFileChooser());
cb.getApproveButtonMnemonic(null);
fail("NullPointerException expected");
} catch (NullPointerException e) {
// expected
}
}
}
----------------------------------------
I suppose this case can be treated as non-bug difference.
Note: The same case with getApproveButtonToolTipText(null) and
cb.getApproveButtonText((JFileChooser) null).
=== cut ===
I would agree with Ilya and vote for closing this issue as non-bug
difference because FileChooserUI methods does not usualy use
FileChooser which is passed as method parameter. So it looks illogical
to throw an exception in few methods and do not throw in others.
Thoughts? Objections?
