harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [classlib][swing] HARMONY-2895 - non-bug difference?
Date Fri, 02 Mar 2007 11:07:27 GMT
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 <alexey.a.petrenko@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 <alexei.zakharov@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 <alexey.a.petrenko@gmail.com>:
> > > 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