[code-reflection] RFR: Add ConstructorRef [v2]

[Paul Sandoz]

On Mon, 14 Apr 2025 23:44:51 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> This is Maurizio's work.
>> This PR tries to make `NewOp` similar to how `InvokeOp` is designed. It does this by adding a descriptor for constructors: `ConstructorRef`.
>> `ConstructorRef` is wrapper around `FunctionType`, providing functionalities for resolution to a reflective instance.
>> Some changes are common between this PR and #393.
>
> Mourad Abbay has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove code that was deleted by a previous PR

Looking good. Can you also please test the examples and HAT?

src/jdk.incubator.code/share/classes/jdk/incubator/code/op/CoreOp.java line 1690:

> 1688:             this(isVarArgs, resultType,
> 1689:                     ConstructorRef.constructor(constructorType), args);
> 1690:         }

Let's remove these methods, so the constructors only accept `ConstructorRef`

src/jdk.incubator.code/share/classes/jdk/incubator/code/op/CoreOp.java line 1724:

> 1722:         public FunctionType constructorType() {
> 1723:             return constructorDescriptor.type();
> 1724:         }

We can remove this method.

src/jdk.incubator.code/share/classes/jdk/incubator/code/type/ConstructorRef.java line 44:

> 42: public sealed interface ConstructorRef extends TypeVarRef.Owner permits ConstructorRefImpl {
> 43: 
> 44:     TypeElement refType();

I am unsure about this method, but make it a default method that returns the result of `type().returnType()`, then the implementation does not need to do anything special. We might need to revisit the terminology, but we can do that later.

src/jdk.incubator.code/share/classes/jdk/incubator/code/type/ConstructorRef.java line 65:

> 63:     static ConstructorRef constructor(Class<?> refType, MethodType mt) {
> 64:         return constructor(refType, mt.parameterList());
> 65:     }

Drop the `refType` parameter and use `mt.returnType()`

src/jdk.incubator.code/share/classes/jdk/incubator/code/type/ConstructorRef.java line 77:

> 75:     static ConstructorRef constructor(TypeElement refType, List<? extends TypeElement> params) {
> 76:         return constructor(functionType(refType, params));
> 77:     }

Add an overloaded method of signature `(TypeElement refType, TypeElement... params)`

src/jdk.incubator.code/share/classes/jdk/incubator/code/type/CoreTypeFactory.java line 131:

> 129:                             constructTypeArgument(tree, 0, NO_WILDCARDS));
> 130:                 } else if (parts.length == 3) {
> 131:                     // method or constructor type-var

This strongly indicates we need to make refs be type elements, perhaps extending from say `JavaRef`, representing the common super class for symbolic references to Java things distinct from a `JavaType`. They formally become part of the code model and then we can manage this more uniformly. We can revisit later (including the distinction between structured string encodings and human readable encodings for Java types and refs).

-------------

PR Review: https://git.openjdk.org/babylon/pull/395#pullrequestreview-2769064565
PR Review Comment: https://git.openjdk.org/babylon/pull/395#discussion_r2045053285
PR Review Comment: https://git.openjdk.org/babylon/pull/395#discussion_r2045055643
PR Review Comment: https://git.openjdk.org/babylon/pull/395#discussion_r2045024340
PR Review Comment: https://git.openjdk.org/babylon/pull/395#discussion_r2045029812
PR Review Comment: https://git.openjdk.org/babylon/pull/395#discussion_r2045032566
PR Review Comment: https://git.openjdk.org/babylon/pull/395#discussion_r2045048385