why in permission ,can't do like this?

[junzhang1983]

public final class MyPermission extends java.security.BasicPermission
{
public MyPermission( String name )
{
super(name);
if ((name == null) ||( !(name.equals("getInstance") ))|| (!
(name.equals("setUtil"))))
throw new IllegalArgumentException();

}
}

in program, use like below:
SecurityManager sm = System.getSecurityManager(); //sm is not null
if (sm != null)
sm.checkPermission( new MyPermission("setUtil") );

when program is running, it will throw Error like below:
java.lang.ExceptionInInitializerError:
java.lang.illegalArgumentException

l don't know why throw above Error,l think add belw code:
if ((name == null) ||( !(name.equals("getInstance") ))|| (!
(name.equals("setUtil"))))
throw new IllegalArgumentException();
will not influence the program,
who can explain why?
thank you.

 

[Peter Duniho]

[...]
l don't know why throw above Error,l think add belw code:
if ((name == null) ||( !(name.equals("getInstance") ))|| (!
(name.equals("setUtil"))))
throw new IllegalArgumentException();
will not influence the program,
who can explain why?

Your condition will _always_ evaluate to true. It's true if the string is
_either_ not equal to "getInstance" or not equal to "setUtil". The string
can never be equal to both at the same time, so it will always be not
equal to at least one of those strings.

You've got an awful lot of parantheses in there, which makes it a lot
harder to read, by the way.

I suspect you'd rather have an if() statement that looks like this:

if (name == null || !(name.equals("getInstance") ||
name.equals("setUtil")))

In other words, the condition is true if "name" is null, or not equal to
either string.

Though, all that said, maybe it's just because I'm unfamiliar with the
BasicPermission class and techniques generally used with it, but it just
feels wrong to me that you allow the client code to pass a string, but
then insist that it must be one of two strings. Maybe there's a better
way to structure that part of the code.

Pete

 

[Lew]

Though, all that said, maybe it's just because I'm unfamiliar with the
BasicPermission class and techniques generally used with it, but it just
feels wrong to me that you allow the client code to pass a string, but
then insist that it must be one of two strings. Maybe there's a better
way to structure that part of the code.

One more verbose way to handle the illegal argument check is with a specific
separate null value check. Though it's verbose, it is nicely
self-documenting. Whether you want to treat null as an out-of-band illegal
value like this depends on the semantics of your application model. It's
perfectly legitimate otherwise to treat null as just another illegal value.

if ( name == null )
{
throw new IllegalArgumentException(
new NullPointerException( "null name" ));
}
if ( name.equals( "getInstance" ))
{
doNameInstanceThing();
}
else if ( name.equals( "setUtil" ))
{
doSetUtilThing();
}
else
{
throw new IllegalArgumentException( "bad name: "+ name );
}

Then I look at that and want doWhatever() methods to be the implementors of a
PermissionHandler interface, selected from a Map based on the passed 'name'
String. Getting null for a Handler from the Map means an illegal argument.

Class <? extends PermissionHandler> clazz = handlers.get( name );
if ( clazz == null )
{
throw new IllegalArgumentException( "bad name: "+ name );
}
PermissionHandler handler = clazz.newInstance();
handler.doWhatever( name );

(error checks omitted)

Then the String 'name' argument can come from, say, a deployment descriptor or
properties file, as can the 'handlers' elements. It makes perfect sense for
code to accept client-driven parameters if it's a framework setup like that.
The clients in this case are disciplined classes working off well-documented
setup files, so they are relatively trustworthy. Of course, the accepting
class must produce meaningful log messages for the operations folks in case
there is a mistake.