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