Access nested annotation value(s) as AnnotationValue(s)

[sebersole]

I am using Byte Buddy in a slightly unusual way here in that I am reading classes and annotations, but not (necessarily) writing stuff. Anyway, the situation I have run into is a problem with nested annotations, both singly and arrays.

An example... Consider this model:

@interface Thing {
  ...
}

@interface Stuff {
  Thing thing();
  Thing[] things();
}

@Stuff( 
    thing = @Thing(...)
    things = { @Thing(...), ... }
)
class MyClass {
}

When I get references to Stuff#thing and Stuff#things from Byte Buddy and access their values via AnnotationValue#resolve, I end up with AnnotationDescription or AnnotationDescription[] for the 2 cases. What I really need is access to the underlying List<? extends AnnotationValue<?, ?>> values that Byte Buddy keeps these things in internally. Unfortunately, when one calls #resolve, it converts each to AnnotationDescription.

The first case I happened upon was AnnotationValue.ForDescriptionArray#values which I was luckily able to access via reflection. However, then another case routed through TypePool$Default$LazyTypeDescription$LazyAnnotationValue$ForArray which I could also (with more difficulty) access via reflection. But I worry about how many cases like this I am going to find. Plus, accessing things this way by reflection is really terrible.

Is there some supported way to accomplish this?

Thanks!

[raphw]

The underlying implementation is a detail as a description might be a reflection representation, or anything really. There is no guarantee to return these values.

Why do you need those? You can get hold of the properties via getDeclaredMethods. Would those not suffice to get hold of all values?

[sebersole]

Hi Rafael! Thanks for the pointers.

You can get hold of the properties via getDeclaredMethods. Would those not suffice to get hold of all values?

Yes that is what I do right now for the ForDescriptionArray case. Then in my tests, the LazyAnnotationValue$ForArray case came up and blew up. Sure I can keep going that way, was just curious if there was something better.

Why do you need those?

It's a long story, but since you asked ... 😁

This is in regards to hibernate-models, which "abstracts away reflection and annotation handling". Basically it is a series of interfaces like ClassDetails, FieldDetails, etc which abstracts from the underlying source of the information. Generally we'd just use reflection (Class, Field, ...), but for potential enhancement cases we don't want to load those things onto the ClassLoader. At the moment we have one "source" for that built on Jandex. But since we already have Byte Buddy and the TypePool available I was looking into a new "source" using that - hibernate/hibernate-models#107

When it comes to parsing annotation information, we use a series of "converters" and "extractors". These, however, need a consistent view of the values being processed. Converter is the important bit here, which for Byte Buddy is built on AnnotationValue. For arrays, we assume we will be able to process the value using this same typing; which works for reflection and for Jandex but this question here is the monkey wrench for implementing this for Byte Buddy.

So to reiterate, yes I can use reflection here. The LazyAnnotationValue$ForArray case is a bit more complicated and unfortunate in that I actually have to use reflection at multiple levels because many of the intermediate types are themselves not accessible.

[sebersole]

So to reiterate, yes I can use reflection here

I guess I need to temper that answer based on

There is no guarantee to return these values.

iiuc.

[raphw]

On first thought, I would argue that resolve would be the right approach here. Potentially, you can also pass the property method's return type with it, and then act accordingly. In this sense, an array is simply a value of itself? You can always access the first element of an AnnotationDescription[], or use the type from the property method's return type. Byte Buddy handles properties like this internally, too, also to avoid incompatible changes through compilations.

[sebersole]

Just a follow-up, I was able to get this working. Yet another way we are using Byte Buddy in Hibernate now! :)

[raphw]

Brilliant! Thanks for the feedback. Glad you found a way. Without reflection?

[sebersole]

Yes sir!

I had to handle this differently than I did for the other "sources", but regardless - got it working without reflection.