Re: [patch] java.security.Permission

[Dalibor Topic <robilad at kaffe dot org>]

Michael Koch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Montag, 7. Juni 2004 14:21 schrieb Jerry Quinn:
>
> > Michael Koch writes:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Am Montag, 7. Juni 2004 07:25 schrieb Jerry Quinn:
> > > > This fixes a java.io.FilePermission.simple failure in mauve. 
> > > > I don't know if it's right, but it seems reasonable.
> > > >
> > > > 2004-06-07  Jerry Quinn  <jlquinn@optonline.net>
> > > >
> > > > 	* java/security/Permission.java (Permission): Reject null
> > > >         name.
> > >
> > > No, its not correct. Neither SUN's API documentation says this
> > > nor a quick test proves your assumption (testcase attached). It
> > > gives no NullPointerException with SUN's JDK 1.4.2.
> >
> > Hmm, ok, a java.io.FilePermission with a null name will throw
> > NullPointerException, even though the API docs don't mention this. 
> > I incorrectly extrapolated that the base class should do this as
> > well.
> >
> > There are mauve tests testing a bunch of misformed inputs to the
> > constructor of java.io.FilePermission, which fail right now, since
> > they expect various errors to be thrown.  The JDK throws these
> > errors in the constructor, but doesn't document the errors being
> > thrown. Our implementation never throws an error.
> >
> > Changing isn't hard, but what's the policy for things like this? 
> > Follow the written docs or emulate the JDK?
>
>
> Emulate JDK in this case. Docs are known to be incomplete or wrong 
> sometimes.

Sun is very bad at specifying the corner cases, like illegal, NPE 
raising input, unfortunately. It usually takes them a few releases of 
the JDK till the specs are reliable for that. So in the corner cases, 
that aren't well specified, I'd say emulate behaviour.

cheers,
dalibor topic