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

(reflect) Please generalize Constructor and Method

    Details

    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 7
    • Fix Version/s: 8
    • Component/s: core-libs
    • Subcomponent:
    • Resolved In Build:
      b01
    • CPU:
      x86
    • OS:
      windows_7
    • Verification:
      Not verified

      Description

      A DESCRIPTION OF THE REQUEST :
      Please generalize Constructor and Method (using an interface or an abstract class).

      Proposed name is CallableMember, but can be otherwise, of course.

      Constructor and Method can be generalized without loss of compatibility and without
      complex/expensive research, specification and testing process.

      These are a lot of common (thus generalizable) methods of these two classes:
       * Class<?>[] getExceptionTypes()
       * Type[] getGenericExceptionTypes()
       * Class<?>[] getParameterTypes()
       * Type[] getGenericParameterTypes()
       * Annotation[][] getParameterAnnotations()
       * TypeVariable<? extends CallableMember>[] getTypeParameters()
         * would be overridden by Method to: TypeVariable<Method>[]
         * would be overridden by Constructor<?> to: TypeVariable<Constructor<?>>[]
       * boolean isSynthetic()
       * boolean isVarArgs()
       * String toGenericString()

      (The generalization of getTypeParameters() can be left out, should it be considered
      as not acceptable because of more specific overrides, or for some reasons.)

      The generalizing abstract class or interface (CallableMember) should also
      implement those interfaces, which are implemented by both Constructor and Method:
       * interface AnnotatedElement
       * interface GenericDeclaration
       * interface Member
       * (in case of abstract class:) AccessibleObject

      Please comment on the idea.

      Best regards,
      Ivan G Shevchenko (assembling DOT signals AT yandex DOT ru)


      JUSTIFICATION :
        Tools which use reflection information could profit from it.
      An other reason for this RFE is the fact, that semantically, methods and constructors represent
      related concepts, especially from the point of view of language syntax.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                darcy Joe Darcy
                Reporter:
                webbuggrp Webbug Group
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: