On Jun 26, 2012, at 9:02 PM, Sanne Grinovero wrote: > There are a lot of libraries depending on Hibernate Commons > Annotations, up to Infinispan for the Query module (not depending on > any other Hibernate core library). > > If you want to rewrite it's internals and provide a drop-in > replacement, that's nice. But I see no reason to throw it away? Sure, here we go. Commons Annotations tries to do two things at the same time. First there is the annotation abstraction, hiding the fact whether an annotation is an actual annotation or a corresponding xml configuration element. It does this  by introducing XClass & Co. And that's the first rub. Working with XClass is highly confusing. You never know whether you deal w/ an XClass or an actual Class instance. Working on the ORM annotation processing code you have often have methods you get one or the other. Confusing! Also, working with Jandex you get the actual annotation vs xml configuration much easier. Jandex itself abstracts already an annotation. Hence you just have to implement  the right Jandex classes to create pseudo annotation (annotation backed by xml configuration). Using Jandex in combination with Commons Annotations would mean you would abstract the abstraction. Back to the two things Commons Annotation tries to do. Commons Annotation also does generic type resolution. IMO this two things should be separate. There is annotation processing and there is type resolution. I often don't need both, but just one of them. Using a library like classmate can easily do the type resolution when I need it in a much more transparent way. The code is actually easily understandable. It is much harder to understand how the corresponding Commons Annotation code works. Regarding your reinventing the wheel argument. The metamodel branch already successfully removed the Commons Annotation dependency. Jandex offers all we need and Strong implemented some classes which create pseudo annotations for the xml config. The type resolution was replaced by classmate. Bottom line is that Commons Annotations is already replaced on the metamodel branch. Last but not least, I am definitely not the guy who wants to rewrite working just for the sake of it. However, if I see that there are better alternatives for existing code which results in easier to understand code I go for it. --Hardy

On 26 Jun 2012, at 21:37, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > Ok that sounds all nice. But we need programmatic definition of > annotations too, you remember Hibernate Search right? How is that conceptually different than XML defined ones?

> The first point you make about the XClass abstraction sounds to me a > good one, a good reason to use it. It doesn't have to be big and > bloated, but if we have a simple way to abstract from the annotation > reading > - XML > - Class definitions > - programmatic overrides That's where the Jandex index comes in. It can abstract all of this and once all the right information is in the index we just use it to process the annotation (real or pseudo ones). > in a single API, that sounds like a good thing? Right, that's what I want as well > You mention this API > is confusing, maybe we can improve on it? Why, when there is a better approach? > Sounds better than to have > to deal with the three sources independently. We won't have to. --hardy

On 26 Jun 2012, at 22:29, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > On 26 June 2012 21:17, Hardy Ferentschik <hardy(a)hibernate.org&gt; wrote: >> >> On 26 Jun 2012, at 21:37, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: >> >>> Ok that sounds all nice. But we need programmatic definition of >>> annotations too, you remember Hibernate Search right? >> >> How is that conceptually different than XML defined ones? > > Not conceptually, but in practice, does Jandex support this directly > or should we add a thin layer of indirection? Kind of directly. You create pseudo annotations the same ways as for XML configuration. Yes, we will have to write some code, but is not adding a new layer. It is just using the Jandex API. Maybe the best is to look at the code in the metamodel branch, because we are actually talking about something which is already done!

One argument I forgot, because I was more focused around why we should get rid of Commons Annotations, is that we actually want to expose the Jandex index when processing annotations (aka using the information in the annotations vs actually discovering them). Using Jandex allows us to clearly separate between annotation discovery and annotation processing. This makes code much easier to write and understand. You can for example just ask the Jandex index to give you all annotations of a certain type (independent of class hierarchies etc). You need much less reflection code when processing the annotations. You would give all this away if you hide it behind the XClass abstraction. You cannot take any advantage of the Jandex API, but you are stuck with the reflect and process approach we currently use. > Plus, you're suggesting we re-wire dependencies in other modules too > right? (like Search) Absolutely! --hardy _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev