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

(reflect) Add the functionality to screen out the "inappropriate" modifier bits

XMLWordPrintable

      FULL PRODUCT VERSION :
      U:\javaclasses>java -version
      java version "1.5.0"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
      Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)

      A DESCRIPTION OF THE PROBLEM :
        Method.getModifers() on a bridge method is returning an int with the
        Modifier.VOLATILE bit set.

        Yes this is the same fault as bug 5070593 which has been closed.
        This IS a bug, and it is easily fixed.

        Wish this to be re-evaluated.

      the spec for Method.getModifiers() says
      "Returns the Java language modifiers for the method represented by this Method
      object, as an integer. The Modifier class should be used to decode the modifiers. "

      While it is true that volatile and bridge share a bit in the JVM acces_flag
      field, "bridge" is not a "java language modifier" and so returning that bit on
      is a bug. Similarly for varargs flag using transient bit.

      Method.getModifiers() should mask out the Modifier.VOLATILE and
      Modifier.TRANSIENT bits, because on methods, these do NOT represent "java
      language modifiers", but have other overloaded uses. Method.isBridge() and
      Method.isVarArgs() are available for testing what these bits actually mean when
      applied to methods.

      Masking the return result from Method.getModifiers() thus alleviates the
      Modifier.toString() problem mentioned in the other fault and apparent in my
      sample code below.

      Constructor.getModifiers() should also mask these bits out.

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      compile and run source code below

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      Modifier.toString(Method.getModifiers()) should return "public"
      ACTUAL -
      Modifier.toString(Method.getModifiers()) returns "public volatile"

      REPRODUCIBILITY :
      This bug can be reproduced always.

      ---------- BEGIN SOURCE ----------
      import java.lang.reflect.*;

      /** our proxy generator generates a volatile proxy for URI.compareTo(). Why? */

      class VolatileMethod {
          public static void main(String[] args) {
              Class<?> uri=java.net.URI.class;
              Method compareTo;
              try {
                  compareTo = uri.getDeclaredMethod("compareTo",Object.class);

                  System.out.format(
                      "method %s in %s%nis Bridge: %b%nis synthetic: %b%nhas modifiers
      %s%n",
                      compareTo,
                      uri,
                      compareTo.isBridge(),
                      compareTo.isSynthetic(),
                      Modifier.toString(compareTo.getModifiers())
                  );
              } catch (Exception e) {
                  e.printStackTrace();
              }
          }
      }
      ###@###.### 2005-04-26 15:59:12 GMT

            darcy Joe Darcy
            tyao Ting-Yun Ingrid Yao (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: