You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
@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.
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.
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?
@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.
Activity
cowtowncoder commentedon Oct 27, 2015
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 commentedon Jul 21, 2016
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 commentedon Jul 21, 2016
@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 commentedon Mar 28, 2018
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 commentedon Mar 29, 2018
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.
CarstenEnglert commentedon Apr 1, 2020
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 commentedon Apr 1, 2020
@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
ResolvedTypewould just have additionprivate final Object extraDatafield, 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.