[patch] java.security.Permission

[Dalibor Topic]

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