On Mon, 17 Apr 2023 21:04:31 GMT, Mandy Chung <[email protected]> wrote:
> Have you considered that the caller of instantiating `MethodTypeDescImpl` is
> responsible for passing a trusted array? I think that `MethodTypeDescImpl`
> implementation already assumes it's a trusted array. So `MethodTypeDesc::of`
> to call `new MethodTypeDescImpl` with a cloned array. `MethodTypeDescImpl`
> should call `new MethodTypeDescImpl` instead of `MethodTypeDesc::of` as this
> PR did.
>
> That way will avoid using `JavaUtilCollectionAccess` to create an immutable
> list without copying the input array.
My plan was that `MethodType` will expose extra entry points:
static MethodTypeDesc of(ClassDesc returnType) {
return of(returnType, List.of());
}
static MethodTypeDesc of(ClassDesc returnType, Collection<ClassDesc>
paramTypes) {
return of(returnType, List.copyOf(paramTypes));
}
The `Collection` version can avoid copying if the user-provided list is already
a null-hostile immutable list. If this API is added, I can safely swap all
existing `new MethodTypeDescImpl` with `MethodTypeDesc.of` without problems.
For the backing structure for parameters, I still believe an immutable list is
better than an array; unlike MethodType that needs to interact with the VM
which loves arrays better, MTD is mainly user-oriented and `parameterList` is
often used by programmers. By avoiding list copies in `parameterList()` alone,
I think there will be immediate benefit to users.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/13186#issuecomment-1512102844
