Hi Steve,
What you suggest sounds good. I've added a comment to
https://hibernate.atlassian.net/browse/HHH-10458 itself.
The reason why I didn't go for this from the beginning just was that I
didn't want to break the contract of SchemaCreator and the other
delegates.
--Gunnar
2016-01-28 19:2
I also plan on adding an @Incubating annotation for just such things :)
Anyway, I will start on this today. It will take a few days though I
think. I'll let you know when I have something ready to look at.
P.S. Do you agree with what I said on your PR wrt TargetBase?
On Fri, Jan 29, 2016 at
2016-01-29 17:18 GMT+01:00 Steve Ebersole :
> I also plan on adding an @Incubating annotation for just such things :)
Yes, please. We have an annotation @Experimental in OGM which we use
for tagging APIs under development.
>
> Anyway, I will start on this today. It will take a few days though I
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
_
On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling
wrote:
> 2016-01-29 17:18 GMT+01:00 Steve Ebersole :
> > I also plan on adding an @Incubating annotation for just such things :)
>
> Yes, please. We have an annotation @Experimental in OGM which we use
> for tagging APIs under development.
>
See ht
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
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
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 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
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 am debating with myself about
reusing `javax.persistence.schema-generation.database.action` and
`javax.persistence.schema-generation.scripts.action`
in terms of this new unified support. The debate point being the fact that
we'd have to have those accept an extended range of values which
potenti
11 matches
Mail list logo
