harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: [classlib][swing] HARMONY-2895 - non-bug difference?
Date Mon, 12 Mar 2007 13:54:42 GMT
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 <alexey.a.petrenko@gmail.com>:
> 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?
>

Mime
View raw message