AnnotatedType support

[luanpotter]

New to Java 8, the AnnotatedType class carries annotations bind to types in Generic expressions. So if I write

@MaxLength(3) List<@NotNull Integer> myField;

I can get the @NotNull annotation via something like:

Field f = MyClass.class.getDeclaredField("myField");
AnnotatedParameterizedType annType = (AnnotatedParameterizedType) field.getAnnotatedType();
AnnotatedType[] childAnnotatedTypes = annType.getAnnotatedActualTypeArguments();

But then I have to assume the parameter I want is the first in the returned array. But maybe I have something like

class MyFunnyList<T> implements List<@NotNull Integer> {}
// ...
private MyFunnyList<@Null String> myFunnyField;

Using ResolvedType, I can call type.typeParametersFor(List.class).get(0) to get the correct parameter type (Integer rather than String). It'd be nice to have also a way to retrieve the annotations associated with it (@NotNull rather than @Null). Note that this feature must not break support for Java 7, so some type of switch will probably need to be used.

[cowtowncoder]

Sounds reasonable in general, but on short term the problem is indeed with JDK compatibility: project only requires JDK 1.6 (Java 6) currently.

[kaqqao]

I've also got into this situation... but when I saw the issue is 2 years old, my heart sank. Is there any hope this feature will be introduced any time soon? I'll try to see if I can implement this myself and make a PR, but my kung-fu on the topic isn't that strong. Regarding JDK 6... well, even JDK 7 is no longer getting updates. Also, one can always use older version of the library is they need it to work in obsolete JDKs.

[cowtowncoder]

@kaqqao Given stability of java-classmate, it could be that old version approach is credible, especially if a maintenance branch is left. Otherwise the problem is that this is a fairly low-level library and as such a dependency for slow(er) moving things.

So: with a PR I would be open to upgrading JDK baseline dependency, and maybe bumping version of classmate itself to 2.0 to signify major change.

[cowtowncoder]

If anyone is interested in working for a PR, I'd be happy to branch of 2.0 for Java 8 baseline, and leave 1.x maintenance branch.

[kaqqao]

As a note, I forked a similar library, GeTyRef, and added support for AnnotatedType. The new library is GeAnTyRef.

With the knowledge obtained in the process, I guess I could help with this, but I'm terribly busy... But when my schedule eventually clears up, I might take a look if no one has stepped up in the meantime.

[CarstenWickner]

Hi @cowtowncoder,

Just warming up this five-year-old issue. I had a look into the code to see what needs to be done, but I'm unsure how to best handle it. I don't want to ruin the performance by ignoring the caching of already resolved types. Would you happen to have some specific ideas for how to go about implementing this?

[cowtowncoder]

@CarstenWickner I do not remember off-hand if I thought about this, but I think that as long as this (whether to collect annotations or not) was behind a switch (configuration setting), having additional optional reference on ResolvedTypes would probably be fine, and just populate it if requested.

Given that it's 2020, raising JDK level from Java 6 to Java 8 would probably be fine as well; would just need to see if minor version upgrade (to 1.6) or major (2.0) would be warranted. Would just create 1.5.x branch for possible patches for possibly (but unlikely) pre-Java8 version.

However... not sure if just storing all annotations for types involved would be sufficient. If not, an alternative would perhaps be to let caller pass an additional optional handler, for processing annotations. Possible so that ResolvedType would just have addition private final Object extraData field, populated by whatever that handler returns.

Does this help? It has been a while since I looked into internals of this library. It is not super-complicated, I think, but I guess as an author I am biased.