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

Undefined type variables now cause TypeNotPresentException

XMLWordPrintable

    • Icon: CSR CSR
    • Resolution: Approved
    • Icon: P4 P4
    • 24
    • core-libs
    • None
    • behavioral
    • low
    • Hide
      Some scenarios that previously don't throw exceptions now do; some TypeNotPresentException handlers may receive these new exceptions. However, the scenarios only apply to malformed generic signatures, which is rare; for TypeNotPresentException handlers, a search on GitHub shows that none of them is dependent on typeName() API.
      Show
      Some scenarios that previously don't throw exceptions now do; some TypeNotPresentException handlers may receive these new exceptions. However, the scenarios only apply to malformed generic signatures, which is rare; for TypeNotPresentException handlers, a search on GitHub shows that none of them is dependent on typeName() API.
    • Java API
    • SE

      Summary

      Now missing Type Variables will lead to TypeNotPresentException when a generic type is accessed. TypeNotPresentException's typeName() getter now may return type variable names.

      Problem

      Missing type variables is specified to cause TypeNotPresentException in its specification, but it was never thrown; missing instances are simply null. This leaks to the downstream and causes confusions in user code,

      Solution

      Make such missing type variables throw TypeNotPresentException with the type variable name eagerly. This is more informative on where the problematic type variable is and what it is, as opposed to a null value somewhere downstream.

      Alternatively, we can pass a dummy type variable that fails upon method access around; this preserves the old failure behavior, but it also allows a problematic instance to be treated as if it's valid, which is still bug-prone and out-of-spec.

      This change will affect all methods on Class, Method, Field, Constructor, Executable, and RecordComponent that returns Type, TypeVariable, or an array type of these types, or the toGenericString methods. It will also affect the array-returning methods in TypeVariable, ParameterizedType, that the other type arguments are no longer accessible, though their specification already allows for such a change. Similarly, annotated type related methods may be affected if they try to annotate a malformed type obtainable via these methods.

      Specification

      --- a/src/java.base/share/classes/java/lang/TypeNotPresentException.java
      +++ b/src/java.base/share/classes/java/lang/TypeNotPresentException.java
      
           /**
      -     * Constructs a {@code TypeNotPresentException} for the named type
      -     * with the specified cause.
      +     * Constructs a {@code TypeNotPresentException} for the named type or
      +     * type variable with the specified cause.
            *
      -     * @param typeName the fully qualified name of the unavailable type
      +     * @param typeName the fully qualified name of the unavailable type or type variable
            * @param cause the exception that was thrown when the system attempted to
            *    load the named type, or {@code null} if unavailable or inapplicable
            */
      @@ -66,9 +66,9 @@ public TypeNotPresentException(String typeName, Throwable cause) {
           }
      
           /**
      -     * Returns the fully qualified name of the unavailable type.
      +     * Returns the fully qualified name of the unavailable type or type variable name.
            *
      -     * @return the fully qualified name of the unavailable type
      +     * @return the fully qualified name of the unavailable type or type variable name
            */
           public String typeName() { return typeName;}
       }

            liach Chen Liang
            winterhalter Rafael Winterhalter
            Joe Darcy
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: