Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4426146

Two-parameter constructor of java.security.BasicPermission

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: P4 P4
    • None
    • 1.3.0
    • security-libs



      Name: boT120536 Date: 03/15/2001


      java version "1.3.0"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
      Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

      Citing the API documentation of java.security.BasicPermission:
      "BasicPermission is commonly used as the base class for "named" permissions
      (ones that contain a name but no actions list; you either have the named
      permission or you don't.)"
      Nevertheless, BasicPermission has two constructors: BasicPermission(String name)
      and BasicPermission(String name, String action). The reason for this second
      constructor is mentioned in the docs: it is used by the Policy object to
      instantiate new Permission objects (while it's not clear to me why the Policy
      object can't use the first constructor).

      When creating a user defined permission (e.g. TestPermission) that extends
      BasicPermission, you _must_ implement a two-parameter constructor, otherwise the
      permission remains unresolved forever, thus failing every checkPermission(). It
      cost me an entire day to find this out; to the best of my knowledge, this is not
      mentioned in any docs.

      For clarity, I give some sample code:

      public class TestPermissionA extends java.security.BasicPermission {
          public TestPermissionA(String name) {
              super(name);
          }
      }

      public class TestPermissionB extends java.security.BasicPermission {
          public TestPermissionB(String name) {
              super(name);
          }
          public TestPermissionB(String name, String action) {
              System.out.println("SECOND CONSTRUCTOR CALLED!");
              super(name, action);
          }
      }

      TestPermissionA seems to remain unresolved after the class has been loaded. Any
      checkPermission on TestPermissionA will fail, even if the policy file grants
      TestPermissionA to the executing CodeSource.
      TestPermissionB works fine. Try it: you will notice that the second constructor
      is actually used by the Policy class, while there might be no reason to
      implement this constructor!
      (Review ID: 114959)
      ======================================================================

            claisunw Charlie Lai (Inactive)
            bonealsunw Bret O'neal (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: