Spec updates for method parameter reflection
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