Hardy, could the API be fixed up? I have not used it enough to be able
to tell if it is salvageable; only enough to know it needs changing ;)
On Tue 26 Jun 2012 02:54:11 PM CDT, Steve Ebersole wrote:
Hardy, could the API be fixed up? I have not used it enough to be
able to tell if it is salvageable (only enough to know it needs
On Tue 26 Jun 2012 02:37:02 PM CDT, Sanne Grinovero wrote:
> 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
> - 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(a)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
>> Hence you just have to implement the right Jandex classes to create
>> pseudo annotation (annotation backed by xml configuration). Using
>> 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
>> alternatives for existing code which results in easier to understand
>> code I go for it.