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

remove implementation inheritance from JSR 292 APIs

    • b135
    • generic
    • generic
    • Not verified

      Initial versions (including the preview in 7/M3) of the JSR 292 API use an undesirable technique for data structure factoring, implementation inheritance. The types MethodHandle and JavaMethodHandle both inherit from JVM-internal supertypes. This pollutes their API, makes unreadable "holes" in their javadoc, and breaks the API filtering performed by javac (as driven by the file "lib/ct.sym").

      A stopgap solution (for javac and the ct.sym file) is to place sun.dyn on the list of packages to allow but not to document.

      The real solution is to remove those private supertypes from those public types.

      Because the implementation types are special-cased by the JVM, this will require a coordinated JVM and java change, with the JVM changes coming first.
      Also, inheritance from MethodHandle must not be exposed via protected or public constructors.

      Fixing this bug must remove all "sun.misc" types from the MethodHandle API.

          Loading...
          Uploaded image for project: 'JDK'
          1. JDK
          2. JDK-6839872

          remove implementation inheritance from JSR 292 APIs

            • b135
            • generic
            • generic
            • Not verified

              Initial versions (including the preview in 7/M3) of the JSR 292 API use an undesirable technique for data structure factoring, implementation inheritance. The types MethodHandle and JavaMethodHandle both inherit from JVM-internal supertypes. This pollutes their API, makes unreadable "holes" in their javadoc, and breaks the API filtering performed by javac (as driven by the file "lib/ct.sym").

              A stopgap solution (for javac and the ct.sym file) is to place sun.dyn on the list of packages to allow but not to document.

              The real solution is to remove those private supertypes from those public types.

              Because the implementation types are special-cased by the JVM, this will require a coordinated JVM and java change, with the JVM changes coming first.
              Also, inheritance from MethodHandle must not be exposed via protected or public constructors.

              Fixing this bug must remove all "sun.misc" types from the MethodHandle API.

                    jrose John Rose
                    jrose John Rose
                    Votes:
                    0 Vote for this issue
                    Watchers:
                    1 Start watching this issue

                      Created:
                      Updated:
                      Resolved:
                      Imported:
                      Indexed:

                        jrose John Rose
                        jrose John Rose
                        Votes:
                        0 Vote for this issue
                        Watchers:
                        1 Start watching this issue

                          Created:
                          Updated:
                          Resolved:
                          Imported:
                          Indexed: