History of using -parameters for JDK builds

[Liam Miller-Cushon]

Thanks Chen,

Another concrete use case for parameter names is for static analysis. For
example an analyzer might want to use parameter names as a signal to detect
cases where arguments are passed to a particular API in the wrong order, to
detect mistakes like:

int index = s.indexOf(fromIndex, '/'); // whoops, fromIndex should be the
second argument

(This hypothetical analyzer would find a bunch of interesting cases where
arguments were deliberately 'swapped' relative to the formal parameter
names, the general point here is just that parameter names are sometimes
interesting to static analyzers.)

Currently the parameter names can sometimes be retrieved from the LVT, but
-parameters would be more reliable.

I think your point about CSRs gets at one of the main challenges with this.
It might require either carefully reviewing existing parameter names and
committing to making them stable, and considering them as part of CSR
reviews; or else trying to set expectations that the names were not part of
the supported interface and people shouldn't rely on them, but they would
anyway, and it would lead to complaints when they changed. So none of this
is something that I'd expect to be done lightly.

On Tue, Jan 28, 2025 at 12:17 PM Chen Liang <chen.l.liang at oracle.com> wrote:

> Hi Liam,
> I believe turning on -parameters is no longer as necessary with the
> introduction of JDK-8292275 <https://bugs.openjdk.org/browse/JDK-8292275>,
> which enforces emission of relevant access flags for parameters that can
> affect core reflection behavior.
> In addition, parameter name changes are not considered in the CSR process;
> relying on them would be risky.
> Another event of note is that due to JDK-8058322
> <https://bugs.openjdk.org/browse/JDK-8058322>, such emitted parameters
> fail core reflection in JDK 8. A fix has since been backported by me.
>
> I believe the main value of parameter is not to reflect on them, but to
> interpret the contents of signatures and annotations.  They omit some
> synthetic or mandated parameters, and only MethodParameters inform users
> which parameters exactly should be omitted.
>
> Regards,
> Chen Liang
> ------------------------------
> *From:* compiler-dev <compiler-dev-retn at openjdk.org> on behalf of Liam
> Miller-Cushon <cushon at google.com>
> *Sent:* Tuesday, January 28, 2025 2:00 PM
> *To:* compiler-dev at openjdk.org <compiler-dev at openjdk.org>
> *Subject:* History of using -parameters for JDK builds
>
> Hi,
>
> I was wondering if anyone on the list knows of prior discussions about
> using -parameters when building the JDK itself. (compiler-dev@ isn't
> exactly the right list but I'm not sure where else to ask,
> enhanced-metadata-spec-discuss@ is archived.)
>
> JEP 118 added support for -parameters and the corresponding model APIs to
> read parameter names. I understand why the change is opt-in, and there's
> some related discussion about that on the lists:
>
>
> https://mail.openjdk.org/pipermail/enhanced-metadata-spec-discuss/2013-May/000200.html
>
> https://mail.openjdk.org/pipermail/enhanced-metadata-spec-discuss/2013-May/000202.html
>
> I was curious if there's been any discussion about enabling the feature
> specifically when building the JDK itself? All of the general concerns
> would apply there as well (class file size, compatibility surface).
>
> I understand this isn't a small change, and am not making an argument for
> doing it, but I'm curious if this has already been considered and there's
> history on the lists I can read up on.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250128/be304564/attachment.htm>