One reason potentially speaking against RUNTIME is that any attributes
of the annotation would be retained as well, e.g. Strings with a
description. So it'd consume a tiny bit of memory which is not needed
by the user application.
Btw. there is a related JEP (http://openjdk.java.net/jeps/277) whic
I don't have anything specific in mind. Just more of a general thought
process, since its the first annotation of this type I am adding.
On Fri, Jan 29, 2016 at 12:11 PM Sanne Grinovero
wrote:
> I would think that such a tool would work at compile time rather than
> reflectively at runtime, bu
I would think that such a tool would work at compile time rather than
reflectively at runtime, but one can't be sure of course so it depends
on what you have in mind.
I'd also say make @Incubating with CLASS retention, it's more than
what people had before.. you can always evolve it later if someo
I personally do not in terms of usage from ORM, nor in usage by ORM users
either. I do wonder about tooling though. Like would it be useful for a
tool to see an implementation of an @Incubating contract being used and
warn the user?
On Fri, Jan 29, 2016, 12:02 PM Gunnar Morling wrote:
> Do you
Do you see any use case for accessing it reflectively at runtime?
FWIW, OGM's @Experimental has CLASS retention, which I think is
"enough retention" for its purpose.
2016-01-29 18:50 GMT+01:00 Steve Ebersole :
> Per HHH-10487[1], I want to add an @Incubating annotation to mark APIs that
> are sti
Per HHH-10487[1], I want to add an @Incubating annotation to mark APIs that
are still incubating. Specifically, what do y'all think of
`java.lang.annotation.RetentionPolicy#CLASS` versus
`java.lang.annotation.RetentionPolicy#RUNTIME`?
[1] https://hibernate.atlassian.net/browse/HHH-10487
_
