<div dir="ltr"><div dir="ltr">Am Mo., 18. Juli 2022 um 15:06 Uhr schrieb Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[...]<br>
<br>
Handling ConstantDescs.NULL is an interesting question.  Since this is a “convenience” method (the user isn’t asking for a specific opcode, they’re saying “here’s a constant, do something”), either treatment of NULL is probably valid.  If we do nothing, you’ll get a condy that evaluates to null, so you get the same runtime behavior, but then again we could LDC an integer constant of zero rather than iconst_0.  So this is probably reasonable behavior to special-case NULL here. </blockquote><div><br></div><div>Besides the symmetry to the other single-byte encodings, having NULL leaves</div><div>room for the application to have its own interpretation of lowercase null.  This is</div><div>what happened to me: every expression node of the compiler has a ConstantDesc</div><div>member, with null signalling that the node cannot be represented by a constant.</div><div>I never call  constantInstruction(null) because here the literal meaning of lowercase</div><div>null is "constantInstruction() is not applicable".</div><div><br></div><div>-- mva</div><div><br></div></div></div>