<div dir="ltr">Thanks Chen,<div><br></div><div>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:</div><div><br></div>int index = s.indexOf(fromIndex, '/'); // whoops, fromIndex should be the second argument<div><br></div><div>(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.)<br><div><br></div><div>Currently the parameter names can sometimes be retrieved from the LVT, but -parameters would be more reliable.</div><div><br></div><div>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.</div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Jan 28, 2025 at 12:17 PM Chen Liang <<a href="mailto:chen.l.liang@oracle.com">chen.l.liang@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg5145662047907663211">




<div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Hi Liam,</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
I believe turning on -parameters is no longer as necessary with the introduction of
<a href="https://bugs.openjdk.org/browse/JDK-8292275" title="https://bugs.openjdk.org/browse/JDK-8292275" target="_blank">
JDK-8292275</a>, which enforces emission of relevant access flags for parameters that can affect core reflection behavior.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
In addition, parameter name changes are not considered in the CSR process; relying on them would be risky.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Another event of note is that due to <a href="https://bugs.openjdk.org/browse/JDK-8058322" target="_blank">
JDK-8058322</a>, such emitted parameters fail core reflection in JDK 8. A fix has since been backported by me.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
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.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Regards,</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Chen Liang</div>
<div id="m_5145662047907663211appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_5145662047907663211divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> compiler-dev <<a href="mailto:compiler-dev-retn@openjdk.org" target="_blank">compiler-dev-retn@openjdk.org</a>> on behalf of Liam Miller-Cushon <<a href="mailto:cushon@google.com" target="_blank">cushon@google.com</a>><br>
<b>Sent:</b> Tuesday, January 28, 2025 2:00 PM<br>
<b>To:</b> <a href="mailto:compiler-dev@openjdk.org" target="_blank">compiler-dev@openjdk.org</a> <<a href="mailto:compiler-dev@openjdk.org" target="_blank">compiler-dev@openjdk.org</a>><br>
<b>Subject:</b> History of using -parameters for JDK builds</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>Hi,</div>
<div><br>
</div>
<div>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.)</div>
<div><br>
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:<br>
</div>
<div><br>
</div>
<div><a href="https://mail.openjdk.org/pipermail/enhanced-metadata-spec-discuss/2013-May/000200.html" target="_blank">https://mail.openjdk.org/pipermail/enhanced-metadata-spec-discuss/2013-May/000200.html</a></div>
<div><a href="https://mail.openjdk.org/pipermail/enhanced-metadata-spec-discuss/2013-May/000202.html" target="_blank">https://mail.openjdk.org/pipermail/enhanced-metadata-spec-discuss/2013-May/000202.html</a></div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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.<br>
</div>
</div>
</div>
</div>

</div></blockquote></div>