[hibernate-dev] Hibernate.next version and AS 7.2 community release...

[Sanne Grinovero]

Ok that sounds all nice. But we need programmatic definition of
annotations too, you remember Hibernate Search right?

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

in a single API, that sounds like a good thing? You mention this API
is confusing, maybe we can improve on it? Sounds better than to have
to deal with the three sources independently.

On 26 June 2012 20:29, Hardy Ferentschik <hardy at hibernate.org> wrote:
>
> 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
>