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

Allow MethodType to encode its components with Strings, not Classes

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: P4
    • Resolution: Unresolved
    • Affects Version/s: 9
    • Fix Version/s: tbd_minor
    • Component/s: core-libs
    • Labels:
      None

      Description

      A class mentioned in field or method descriptor is not checked for accessibility by the VM. Nor must the named class be visible to the mentioning class's class loader [1], or even to any class loader at all [2].

      However, the design of java.lang.invoke requires all MethodTypes to be encoded with Class objects, which necessitates loading appropriate classes; the resolution of CONSTANT_MethodType structures in class files (JVMS 5.4.3.5) further requires an accessibility check.

      This means that certain perfectly valid invocations, declarations, etc., cannot be successfully described abstractly using MethodTypes and MethodHandles. E.g., were a class file to be preprocessed, replacing all its invokestatic instructions with "equivalent" invokedynamic instructions, new errors could occur, as the VM attempted to resolve classes that, in the original bytecode, would be left unresolved.

      To address this limitation, I suggest exploring the possibility of enhancing MethodType to represent its component types as Strings as an alternative to Classes. That may be a rather deep change, but as is the feature can't live up to its promise of equivalence with concrete bytecode. (Expressiveness aside, it's also a potential performance problem to require every mentioned class to be loaded immediately.)

      As a followup, resolution of CONSTANT_MethodType (JVMS 5.4.3.5) could then be modified to avoid loading any classes.

      -----

      [1] Class loader constraints ensure that two class loaders agree on the meaning of a name in a declaration/use or overrider/overridee scenario -- but *only if* both class loaders attempt to load a class with that name. If one of them never loads such a class, the constraint cannot be violated.

      ----

      [2] Example of a class name that goes completely unresolved:

      Source file: ResolutionTest.java:

      -

      public class ResolutionTest {
          public static void main(String... args) {
              System.out.println(C.f);
              System.out.println(C.m());
          }
      }
      class C {
          static Missing f;
          static Missing m() { return null; }
      }
      class Missing {}

      -

      javac ResolutionTest.java
      rm Missing.class
      java ResolutionTest

      Output:
      null
      null

      (In practice, this kind of thing might arise if the classes for an optional feature of some system are sometimes unavailable.)

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              dlsmith Dan Smith
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated: