changing a parameter name will never be a binary-incompatible change

Alex Buckley alex.buckley at oracle.com
Thu May 2 16:22:24 PDT 2013


I appreciate your thorough reading of the 8misc.pdf file. In this 
instance, I can set your mind at rest. The file contains updates to 
numbered sections of the JLS and JVMS, but also motivation and rationale 
for the features. The text you quote from 2.1 is just that - motivation 
for the attribute definition which follows in 4.7.22. If that part of 
2.1 even makes it into JVMS8, it would at most be non-normative text in 
4.7.22, probably shortened and softened.

Accordingly, there's no need to worry that JVMS8 might bind its 
successors by stating normatively that something "will never be".

Alex

On 5/2/2013 5:56 AM, Markus Keller wrote:
> Section 2.1 of "Method Parameter Reflection" says:
> "1. Parameter names are not essential to the Java virtual machine. They
> play no part
> in linkage, so changing a parameter name will never be a
> binary-incompatible
> change."
>
> Is the "will never be" really necessary? Is it absolutely impossible that
> the JVM will at one point get a new instruction that will perform method
> lookup by parameter name? Maybe not for the Java language, but to better
> support other languages.
>
> The "will never be" would make such an evolution illegal. I think it's
> better to just say "[..], so changing a parameter name is a
> binary-compatible change.". That's clear enough for now, but leaves the
> door open for developments in a new version of the spec.
>
> Markus
>


More information about the enhanced-metadata-spec-discuss mailing list