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

[Steve Ebersole]

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
> changing ;)
>
> 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
>> 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
>>>

--
steve at hibernate.org
http://hibernate.org