Reflection API: Why no support for attributes

[Alex Suzuki]

Hi there,

I am working on a semester thesis that deals with storing extended
type information in the .class file. The way I do it is via field,
method and class attributes (JVM spec. chapter 4.7). This all works
well, but it would be nice to be able to use reflection at run-time
to get back the information at run-time. However, java.lang.reflect
has no support for attributes.

Does anyone know if there is a reason for this? I know BCEL does it,
but I was wondering if maybe SUN deliberately chose to not include
support for attributes in the Reflection API, and if so, why.

Regards,
Alex

 

[Chris Uppal]

Does anyone know if there is a reason for this? I know BCEL does it,
but I was wondering if maybe SUN deliberately chose to not include
support for attributes in the Reflection API, and if so, why.

The only reason I can imagine is to allow JVM implementations to ignore /and
discard/ attribute data for which they have no use. If there were reflective
access to the attributes then the JVM would have to keep everything, even if it
had no use for it itself. (I'm not convinced that is a /good/ reason, but it's
the only one I can think of...)

I believe the new annotations stuff in 1.5 is supposed to fulfill the
design-requirement for embedding arbitrary meta-data in a classfile.

-- chris

 

[Alex Suzuki]

Chris,

The only reason I can imagine is to allow JVM implementations to ignore /and
discard/ attribute data for which they have no use. If there were reflective
access to the attributes then the JVM would have to keep everything, even if it
had no use for it itself. (I'm not convinced that is a /good/ reason, but it's
the only one I can think of...)

I just read up on the JVM specification again, and it says (chapter 4.7.1):

"However, any attribute not defined as part of this Java virtual machine
specification must not affect the semantics of class or interface types."

I guess that is pretty much the reason. Any dependency on a non-standard
attribute (which would be possible if the Reflection API allowed access
to attributes) in for instance a method would affect its semantics. Your
comment brought me on the right track.

I believe the new annotations stuff in 1.5 is supposed to fulfill the
design-requirement for embedding arbitrary meta-data in a classfile.

Yes, I read about annotations, but for my particular project, attributes
were the simpler choice.

cheers,
Alex

 

[Alex Suzuki]

Yes, I read about annotations, but for my particular project, attributes
were the simpler choice.

Also, the compiler on top of which I'm implementing the new functionality
does not yet support annotations ;-)

cheers,
Alex

 

[Chris Uppal]

I just read up on the JVM specification again, and it says (chapter
4.7.1):

"However, any attribute not defined as part of this Java virtual
machine specification must not affect the semantics of class or
interface types."

I guess that is pretty much the reason. Any dependency on a non-standard
attribute (which would be possible if the Reflection API allowed access
to attributes) in for instance a method would affect its semantics.

Hmm... I'm not convinced. If a getAttributeValue(String name) method existed
as part of the reflection stuff, then the presence or absence of a
(non-standard) attribute wouldn't be changing "the semantics of class or
interface types" -- the /semantics/ would be the same in all cases, but the
data retrieved through the API would be variable. Much in the same way as the
/semantics/ of the various System.getProperty() methods aren't considered to
change with different values for properties.

-- chris

 

[Chris Uppal]

Also, the compiler on top of which I'm implementing the new functionality
does not yet support annotations ;-)

A very good reason !

(And it wouldn't be trivial to use annotations even if they were supported. At
least at the classfile level the data structures seem to be pretty intricate --
I looked at adding support for them to my own classfile parser/builder but
decided it was too complicated to be worth the effort for the time being.)

-- chris

 

[Alex Suzuki]

Chris,

Hmm... I'm not convinced. If a getAttributeValue(String name) method existed
as part of the reflection stuff, then the presence or absence of a
(non-standard) attribute wouldn't be changing "the semantics of class or
interface types" -- the /semantics/ would be the same in all cases, but the
data retrieved through the API would be variable. Much in the same way as the
/semantics/ of the various System.getProperty() methods aren't considered to
change with different values for properties.

You're probably right, I was jumping to conclusions. I guess the quoted part
of the specification was referring to the JVM level. A JVM recognizing a
particular non-standard attribute is not allowed to take special actions
that would not be taken if that attribute was not there.

cheers,
Alex