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

Lookup::in should not allow target class be primitive or array class

    XMLWordPrintable

    Details

    • Type: CSR
    • Status: Closed
    • Priority: P3
    • Resolution: Approved
    • Fix Version/s: 14
    • Component/s: core-libs
    • Labels:
      None
    • Subcomponent:
    • Compatibility Kind:
      behavioral
    • Compatibility Risk:
      low
    • Compatibility Risk Description:
      Hide
      Existing code calling `Lookup::in` on a primitive type, void or array type will
      fail with IAE. It is expected that most users of Lookup::in will
      teleport to a non-array and non-primitve class as that's the original
      assumption of a lookup class be non-primitive and non-array type.
      So the compatibility risk is expected low.
      Show
      Existing code calling `Lookup::in` on a primitive type, void or array type will fail with IAE. It is expected that most users of Lookup::in will teleport to a non-array and non-primitve class as that's the original assumption of a lookup class be non-primitive and non-array type. So the compatibility risk is expected low.
    • Interface Kind:
      Java API
    • Scope:
      SE

      Description

      Summary

      Lookup::in throws IllegalArgumentException if the target class is a primitive type, void or an array class.

      Problem

      The current spec of Lookup::in allows to produce a Lookup object on a primitive type, void or an array class which is against the original design that assumes the lookup class of a Lookup object is never non-array and non-primitive class (method handle lookup is as if a specified member is referenced via bytecode)

      The static factory methods MethodHandles::lookup, MethodHandles::privateLookupIn never produce a Lookup object on primitive type, void or array class.

      Solution

      Change the spec of Lookup::in to throw IllegalArgumentException if requestedLookupClass is a primitive type, void or array type.

      An alternative would be that Lookup::in returns a Lookup object successfully but drop all lookup modes if requestedLookupClass is a primitive type, void or array type. This delays the failure point to method handle lookup time. It makes it harder to diagnose if any existing code is depending on the existing behavior.

      It is expected that it's rare for existing code to call Lookup::in on a primitive type, void or array type. It'd be more helpful to throw IAE when a bad requestLookupClass argument is passed to Lookup::in.

      Specification

      The spec of Lookup::in method has the following new @throws IAE:

      +         * @throws IllegalArgumentException if {@code requestedLookupClass} is a primitive type or void or array class

      @throw IAE in the spec of MethodHandles::privateLookupIn method is updated to explicitly call out void:

      -     * @throws IllegalArgumentException if {@code targetClass} is a primitive type or array class
      +     * @throws IllegalArgumentException if {@code targetClass} is a primitive type or void or array class

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              mchung Mandy Chung
              Reporter:
              alanb Alan Bateman
              Reviewed By:
              Alan Bateman
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: