You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alexey Petrenko <al...@gmail.com> on 2007/03/02 08:39:41 UTC
[classlib][swing] HARMONY-2895 - non-bug difference?
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?
Re: [classlib][swing] HARMONY-2895 - non-bug difference?
Posted by Alexei Zakharov <al...@gmail.com>.
The spec for this method is odd. The only thing it describes is this
JFileChooser parameter. :) Why do you think it is not used by RI? The
exception is thrown directly from getApproveButtonMnemonic() method:
.java.lang.NullPointerException
at javax.swing.plaf.basic.BasicFileChooserUI.getApproveButtonMnemonic(BasicFileChooserUI.java:651)
at test.testRun(test.java:16)
Regards,
2007/3/2, Alexey Petrenko <al...@gmail.com>:
> No. I mean that FileChooser parameter which is passed to FileChooserUI
> methods is not usually used both in Harmony and RI.
>
> 2007/3/2, Alexei Zakharov <al...@gmail.com>:
> > Yeah, but you probably mean the Harmony code, right? This does not
> > prevent the situation when users will expect NPE after passing null.
> > BTW I can say I've already seen several places in Harmony code there
> > NPE (or some other exception) is thrown just because RI throws it;
> > corresponding parameters also weren't used in code. We may add a
> > comment like
> > // throw NPE just to be compatible with RI
> > or something like it in such cases.
> >
> > Regards,
> >
> > 2007/3/2, Alexey Petrenko <al...@gmail.com>:
> > > The code does not use this parameter.
> > >
> > > 2007/3/2, Alexei Zakharov <al...@gmail.com>:
> > > > Hi Alexey,
> > > >
> > > > IMO throwing NPE if one of method's parameters is null is something
> > > > natural and generally expected behavior. I agree that the situation
> > > > when some methods throw NPE and others don't throw it is not very
> > > > good. But IMHO it will be worse if some real-world application fails
> > > > because of this incompatibility. I suppose it is better not to think
> > > > about it too much - just fix it (if it is easy). However, if such fix
> > > > is not an easy one and requires rework of some fundamental concepts
> > > > (we just saw such example in "[classlib][awt] JUnit AWT TestRunner:
> > > > menu should disappear after pressing ALT key" thread) then I will vote
> > > > for filing NBD.
> > > >
> > > > The patch for HARMONY-2895 does not look like a big rework.
> > > >
> > > > Thanks,
> > > >
> > > > 2007/3/2, Alexey Petrenko <al...@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?
--
Alexei Zakharov,
Intel ESSD
Re: [classlib][swing] HARMONY-2895 - non-bug difference?
Posted by Alexey Petrenko <al...@gmail.com>.
No. I mean that FileChooser parameter which is passed to FileChooserUI
methods is not usually used both in Harmony and RI.
2007/3/2, Alexei Zakharov <al...@gmail.com>:
> Yeah, but you probably mean the Harmony code, right? This does not
> prevent the situation when users will expect NPE after passing null.
> BTW I can say I've already seen several places in Harmony code there
> NPE (or some other exception) is thrown just because RI throws it;
> corresponding parameters also weren't used in code. We may add a
> comment like
> // throw NPE just to be compatible with RI
> or something like it in such cases.
>
> Regards,
>
> 2007/3/2, Alexey Petrenko <al...@gmail.com>:
> > The code does not use this parameter.
> >
> > 2007/3/2, Alexei Zakharov <al...@gmail.com>:
> > > Hi Alexey,
> > >
> > > IMO throwing NPE if one of method's parameters is null is something
> > > natural and generally expected behavior. I agree that the situation
> > > when some methods throw NPE and others don't throw it is not very
> > > good. But IMHO it will be worse if some real-world application fails
> > > because of this incompatibility. I suppose it is better not to think
> > > about it too much - just fix it (if it is easy). However, if such fix
> > > is not an easy one and requires rework of some fundamental concepts
> > > (we just saw such example in "[classlib][awt] JUnit AWT TestRunner:
> > > menu should disappear after pressing ALT key" thread) then I will vote
> > > for filing NBD.
> > >
> > > The patch for HARMONY-2895 does not look like a big rework.
> > >
> > > Thanks,
> > >
> > > 2007/3/2, Alexey Petrenko <al...@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?
>
>
> --
> Alexei Zakharov,
> Intel ESSD
>
Re: [classlib][swing] HARMONY-2895 - non-bug difference?
Posted by Alexei Zakharov <al...@gmail.com>.
Yeah, but you probably mean the Harmony code, right? This does not
prevent the situation when users will expect NPE after passing null.
BTW I can say I've already seen several places in Harmony code there
NPE (or some other exception) is thrown just because RI throws it;
corresponding parameters also weren't used in code. We may add a
comment like
// throw NPE just to be compatible with RI
or something like it in such cases.
Regards,
2007/3/2, Alexey Petrenko <al...@gmail.com>:
> The code does not use this parameter.
>
> 2007/3/2, Alexei Zakharov <al...@gmail.com>:
> > Hi Alexey,
> >
> > IMO throwing NPE if one of method's parameters is null is something
> > natural and generally expected behavior. I agree that the situation
> > when some methods throw NPE and others don't throw it is not very
> > good. But IMHO it will be worse if some real-world application fails
> > because of this incompatibility. I suppose it is better not to think
> > about it too much - just fix it (if it is easy). However, if such fix
> > is not an easy one and requires rework of some fundamental concepts
> > (we just saw such example in "[classlib][awt] JUnit AWT TestRunner:
> > menu should disappear after pressing ALT key" thread) then I will vote
> > for filing NBD.
> >
> > The patch for HARMONY-2895 does not look like a big rework.
> >
> > Thanks,
> >
> > 2007/3/2, Alexey Petrenko <al...@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?
--
Alexei Zakharov,
Intel ESSD
Re: [classlib][swing] HARMONY-2895 - non-bug difference?
Posted by Alexey Petrenko <al...@gmail.com>.
The code does not use this parameter.
2007/3/2, Alexei Zakharov <al...@gmail.com>:
> Hi Alexey,
>
> IMO throwing NPE if one of method's parameters is null is something
> natural and generally expected behavior. I agree that the situation
> when some methods throw NPE and others don't throw it is not very
> good. But IMHO it will be worse if some real-world application fails
> because of this incompatibility. I suppose it is better not to think
> about it too much - just fix it (if it is easy). However, if such fix
> is not an easy one and requires rework of some fundamental concepts
> (we just saw such example in "[classlib][awt] JUnit AWT TestRunner:
> menu should disappear after pressing ALT key" thread) then I will vote
> for filing NBD.
>
> The patch for HARMONY-2895 does not look like a big rework.
>
> Thanks,
>
> 2007/3/2, Alexey Petrenko <al...@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?
> >
>
>
> --
> Alexei Zakharov,
> Intel ESSD
>
Re: [classlib][swing] HARMONY-2895 - non-bug difference?
Posted by Alexei Zakharov <al...@gmail.com>.
Hi Alexey,
IMO throwing NPE if one of method's parameters is null is something
natural and generally expected behavior. I agree that the situation
when some methods throw NPE and others don't throw it is not very
good. But IMHO it will be worse if some real-world application fails
because of this incompatibility. I suppose it is better not to think
about it too much - just fix it (if it is easy). However, if such fix
is not an easy one and requires rework of some fundamental concepts
(we just saw such example in "[classlib][awt] JUnit AWT TestRunner:
menu should disappear after pressing ALT key" thread) then I will vote
for filing NBD.
The patch for HARMONY-2895 does not look like a big rework.
Thanks,
2007/3/2, Alexey Petrenko <al...@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?
>
--
Alexei Zakharov,
Intel ESSD
Re: [classlib][swing] HARMONY-2895 - non-bug difference?
Posted by Alexey Petrenko <al...@gmail.com>.
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 <al...@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?
>