Spec updates for method parameter reflection

Alex Buckley alex.buckley at oracle.com
Mon Nov 12 15:58:15 PST 2012

On 11/12/2012 3:38 PM, Leonid Arbouzov wrote:
> Anyway, thanks for your answers.
> This makes it clear that the option indeed similar to -g option of javac
> and thus not a subject of Java compiler conformance testing...
> Could this create some compatibility problems?
> For example,  one replaces Java+compiler version with
> other version and discovers that it's product fails at runtime because
> parameter names info missed? Would it be of any concern?
> Does it mean we care mostly about runtime compatibility in that case?

Compilers are free to put optional JVMS-defined attributes into class 
files today and it is up to the reflective client to handle their 
presence or absence. General questions of behavioral compatibility for 
the client are not the platform's concern. If attributes like 
MethodParameters or RuntimeVisibleAnnotations were once present in a 
class file, they may have been stripped (via pack200) by the time a 
client reflects over that class file. The java.lang.reflect API in such 
cases simply returns zero answers.


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