Fwd: Mandated/implicit parameters

[-]

I strongly agree with your recommended solution of forcing javac to emit
MethodParameters attribute without names when -parameters flag is absent.
This is related to JDK-8062582.

In fact, the main manifest of this lack of necessary parameter data is
rendered in the loss of generics when an inner class (with an implicit
outer class as first constructor argument) is scanned. For instance, in
Apple.java:

import java.lang.annotation.*;
import java.lang.reflect.*;
import java.util.*;
import java.util.function.*;

public class Apple {
    @Retention(RetentionPolicy.RUNTIME)
    @Target(ElementType.TYPE_USE)
    public @interface Anno {}

    public class Inner {
        public Inner(Optional<@Anno String> argument) {}
        public void test(Optional<@Anno String> argument) {}
    }

    public static void main(String... args) throws Throwable {
        System.out.println("Test constructor:");
        Constructor<?> ctor =
Inner.class.getDeclaredConstructor(Apple.class, Optional.class);
        printTypes(ctor);
        printParam(ctor.getParameters()[1]);
        System.out.println();

        System.out.println("Test method:");
        Method test = Inner.class.getDeclaredMethod("test", Optional.class);
        printTypes(test);
        printParam(test.getParameters()[0]);
        System.out.println();
    }

    private static void printTypes(Executable exec) {

System.out.println(Arrays.toString(exec.getGenericParameterTypes()));

System.out.println(Arrays.toString(exec.getAnnotatedParameterTypes()));
    }

    private static void printParam(Parameter parameter) {
        System.out.println(parameter.getParameterizedType());
        System.out.println(parameter.getAnnotatedType());
    }
}

Compile and run it in JDK 18 (without -parameters), and observe on the
inner class constructor the loss of annotations and loss of generics when
inspected through parameters:
Test constructor:
[java.util.Optional<java.lang.String>]
[Apple, java.util.Optional] // Comment: from getAnnotatedParameterTypes,
the Optional lost generics and thus, annotations
class java.util.Optional // This one doesn't depend on annotations, yet it
lost generics
java.util.Optional

Test method:
[java.util.Optional<java.lang.String>]
[java.util.Optional<@Apple$Anno() java.lang.String>]
java.util.Optional<java.lang.String>
java.util.Optional<@Apple$Anno() java.lang.String>

And this issue goes away when -parameters flag is enabled.
A similar issue exists at JDK-8284333.

So, your approach would fix all these issues reported. It all goes down to
satisfying the logic in Executable::getAllGenericParameterTypes, which can
fix (generic) signature and formal parameter count mismatch only with the
presence of MethodParameters attribute. In addition, we can move away from
the hacky, java-specific logic. in
https://github.com/openjdk/jdk/blob/e990fec195791e17ea8af5c5393fec1c92cb4717/src/java.base/share/classes/sun/reflect/annotation/TypeAnnotationParser.java#L130
and
https://github.com/openjdk/jdk/blob/e990fec195791e17ea8af5c5393fec1c92cb4717/src/java.base/share/classes/java/lang/reflect/Executable.java#L582

On Wed, May 25, 2022 at 9:43 AM Hannes Greule <hannesgreule at outlook.de>
wrote:

> > It would be legitimate to emit MethodParameters without -parameters, so
> as to record `final` and "implicitly declared" but not the parameter name,
> but at some cost to implementation complexity in java.lang.reflect.
>
> What implementation complexity are you thinking of? The JVMS says "If the
> value of the name_index item is zero, then this parameters element
> indicates a formal parameter with no name."[1].
> Shouldn't this case be already handled by the reflect impl?
>
> Wouldn't it be also possible to just emit the attribute *with* names when
> it contains a mandated parameter? This would solve the problem with minimal
> changes as far as I can tell (with the downside of slightly increased class
> file sizes in such cases).
>
> > That is weird, and sounds like a javac bug.
> What would be the next steps here? Is my linked solution feasible?
>
> Hannes
>
> [1]
> https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-4.html#jvms-4.7.24
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220525/89395860/attachment-0001.htm>