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

5.3, 5.4: Better specify the treatment of array types



    • Bug
    • Resolution: Unresolved
    • P4
    • tbd
    • 21
    • specification
    • vm


      JVMS often seems to lump array types in with classes. But array types have their own descriptors, don't really need "loading", don't declare members, and are allowed in some places while being disallowed in others. Sometimes it's not clear whether a rule applies to array types or only true classes (and, sometimes, interfaces). The spec would be improved in general if array types were acknowledged and handled as distinct entities.

      Some specific changes:

      - 5.3: Classes and interfaces are loaded. Array types (or "array classes", a misnomer) are not. "Nonarray class" is not a meaningful term.

      - 5.3.3: Specifically, there is no need to record an "initiating loader" of an "array class", or to check its accessibility. This section can be deleted (resulting, unfortunately, in some renumbering of later sections).

      - 5.1: A CONSTANT_Class_info encodes a symbolic reference to a *class*, *interface*, or *array type*

      - Should explicitly specify resolution of an array type (by recursively resolving its element type, then constructing an abstract "representation" of the array type)

      - Array types don't have fields, but the resolution algorithm should be specified anyway (maybe they will someday!), treating Object as the superclass and Serializable/Cloneable as superinterfaces.

      - Array types *can* be used to invoke methods, and method resolution should account for them. Again, resolution should search Object and Serializable/Cloneable.

      - 5.4.4: The 'Object.clone' method is considered 'public' if accessed via an array type. An error occurs if a NestHost is an array type (confirmed on HotSpot and OpenJ9).

      - 5.4.6, invokeinterface, invokevirtual: Method selection may occur with respect to an array type, recurring on class Object

      - handle array types as a distinct case for class_info_index, parallel to class types and primitive types

      - 5.4.3,,,, anewarray, checkcast, getfield, getstatic, instanceof, invokespecial, invokestatic, ldc, ldc_w, multianewarray, putfield, putstatic: "class, interface, or array type" is how we should refer collectively to the things represented by Class constant (unless format checking has limited what can appear here)


        Issue Links



              dlsmith Dan Smith
              dlsmith Dan Smith
              0 Vote for this issue
              1 Start watching this issue