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 Fri, 02 Mar 2007 09:52:28 GMT
The code does not use this parameter.

2007/3/2, Alexei Zakharov <alexei.zakharov@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 <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?
> >
>
>
> --
> Alexei Zakharov,
> Intel ESSD
>

Mime
View raw message