-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
-
None
-
None
This was prompted by discussion in https://bugs.openjdk.org/browse/JDK-8319330.
javac's implementation of `ExecutableElement.getReceiverType()` and `ExecutableType.getReceiverType()` currently return a type whenever a receiver parameter is explicitly declared in source, and otherwise a 'NoType' type mirror.
https://bugs.openjdk.org/browse/JDK-8319196 tracks updating the implementation to also return a receiver type for executables loaded from bytecode when the receiver type has type use annotations.
The current specification includes:
> An executable which is an instance method, or a constructor of an inner class, has a receiver type derived from the [declaring type](https://docs.oracle.com/en/java/javase/21/docs/api/java.compiler/javax/lang/model/element/ExecutableElement.html#getEnclosingElement())
This can be read as suggesting that getReceiverType() should return a type for executables that have a receiver, not just for executables that have a receiver that is explicit denoted in source, or that have type use annotations.
However the current implemented behavior seems useful in practice: the receiver parameter syntax was implemented to allow type use annotations to be placed on the type, and having getReceiverType() return a type if the syntax is present (or if annotations are present on the receiver type) fulfills that use-case. It also provides more information than having getReceiverType() return a type for all executables that have a receiver, since it allows clients to tell whether or not the syntax was present in the modeled source code.
This feature request tracks updating the specification to make the current behavior more clear.
The resolution could involve:
* Updating the getReceiverType() specification to state that receiver types are returned if a receiver parameter was explicitly provided in source
* Updating the package-level disclaimer in javax.lang.model.element to mention receiver types as a situation where 'the process of translating source code to executable output may not permit recovering some aspects of the source code representation'
javac's implementation of `ExecutableElement.getReceiverType()` and `ExecutableType.getReceiverType()` currently return a type whenever a receiver parameter is explicitly declared in source, and otherwise a 'NoType' type mirror.
https://bugs.openjdk.org/browse/JDK-8319196 tracks updating the implementation to also return a receiver type for executables loaded from bytecode when the receiver type has type use annotations.
The current specification includes:
> An executable which is an instance method, or a constructor of an inner class, has a receiver type derived from the [declaring type](https://docs.oracle.com/en/java/javase/21/docs/api/java.compiler/javax/lang/model/element/ExecutableElement.html#getEnclosingElement())
This can be read as suggesting that getReceiverType() should return a type for executables that have a receiver, not just for executables that have a receiver that is explicit denoted in source, or that have type use annotations.
However the current implemented behavior seems useful in practice: the receiver parameter syntax was implemented to allow type use annotations to be placed on the type, and having getReceiverType() return a type if the syntax is present (or if annotations are present on the receiver type) fulfills that use-case. It also provides more information than having getReceiverType() return a type for all executables that have a receiver, since it allows clients to tell whether or not the syntax was present in the modeled source code.
This feature request tracks updating the specification to make the current behavior more clear.
The resolution could involve:
* Updating the getReceiverType() specification to state that receiver types are returned if a receiver parameter was explicitly provided in source
* Updating the package-level disclaimer in javax.lang.model.element to mention receiver types as a situation where 'the process of translating source code to executable output may not permit recovering some aspects of the source code representation'