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 <ha...@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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
