Skip to content

AnnotatedType support #25

Open
Open

Description

@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.

Activity

  1. cowtowncoder commented on Oct 27, 2015

    @cowtowncoder
    Member

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

  2. kaqqao commented on Jul 21, 2016

    @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.

  3. cowtowncoder commented on Jul 21, 2016

    @cowtowncoder
    Member

    @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.

  4. cowtowncoder commented on Mar 28, 2018

    @cowtowncoder
    Member

    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.

  5. kaqqao commented on Mar 29, 2018

    @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.

  6. CarstenEnglert commented on Apr 1, 2020

    @CarstenEnglert

    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?

  7. cowtowncoder commented on Apr 1, 2020

    @cowtowncoder
    Member

    @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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions