govern applets. Without such an object, a Java application will not even attempt to
load classes that are not from its local fi le system.
Though the security policy can be modifi ed by use of the Java utility policytool ,
this can be done only for individual hosts, so it is probably more straightforward to
write and install one's own security manager. There is a default RMISecurityManager ,
but this relies on the system's default security policy, which is far too restrictive to
permit the downloading of class fi les from a remote site. In order to get round this
problem, we must create our own security manager that extends RMISecurityManager .
This security manager must provide a defi nition for method checkPermission , which
takes a single argument of class Permission from package java.security . For sim-
plicity's sake and because the complications involved with specifying security poli-
cies go beyond the scope of this text, we shall illustrate the procedure with the
simplest possible security manager—one that allows everything! The code for this
security manager is shown below.
public class ZeroSecurityManager
public void checkPermission(Permission permission)
System.out.println("checkPermission for : "
As with all our associated RMI application fi les, this fi le must be compiled with
javac . The client program must install an object of this class by invoking method
setSecurityManager , which is a static method of class System that takes a single argu-
ment of class SecurityManager (or a subclass of SecurityManager , of course). For
illustration purposes, the code for our HelloClient program is reproduced below, now
incorporating a call to setSecurityManager . This call is shown in emboldened text.
public class HelloClient
private static fi nal String HOST = "localhost";
public static void main(String args)
//Here's the new code…
if (System.getSecurityManager() == null)