[hibernate-dev] Reflite

[Gunnar Morling]

2014-06-03 15:44 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> The point is to delay accessing ClassLoader.  The reason being runtime
> enhancement.  If we load Classes at this point we wont be able to enhance
> them later when JPA hooks allow us to.
>

Ah, I see.

FWIW, the model in javax.lang.model.type.* also doesn't require to actually
load classes (as it's original purpose is to represent types during
compilation where class objects naturally do not exist yet). Whether a
custom implementation of that model would fit your need, I don't know :)

On Tue, Jun 3, 2014 at 8:33 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> Hi,
>>
>> I haven't followed the discussion around "reflite" closely, so I'm just
>> going to add some thoughts/questions coming to my mind after exploring the
>> model a bit:
>>
>> * Is there some sort of design document which describes at a higher level
>> the purpose and the benefit of the model? If not, e.g. JavaDocs on the
>> package level (or one of the new topical guides) would be great for that.
>>
>> * What is the primary motivation for having this model, is it about
>> ease-of-use or performance (through Jandex) compared to using plain
>> reflection, or something else?
>>
>> * The "reflite" model remembers me a bit of the one in
>> javax.lang.model.type.* [1]. So if the aim of "reflite" is to provide a
>> "complete" model which can represent each and every specific of the Java
>> type system, it might make sense to implement this pre-defined model (it's
>> all interfaces) based on Jandex/ClassMate instead of defining a custom
>> model. But if we're only interested in a specific sub-set of the Java
>> type-model, having a custom model probably is the better choice as it
>> provides a simpler-to-use contract (and it may allow for a
>> "domain-specific" language, e.g. by working with concepts such as "entity"
>> instead of the generic "Java type").
>>
>> * Regarding a "collapsed" representation of type information (as done by
>> java.lang.Class) vs. a hierarchy of specialized types, I think it depends
>> on the usage patterns. With the current approach, how are clients supposed
>> to take action depending on the specific type of a descriptor (if they have
>> a reference to the super-type of the hierarchy)? Via instanceof calls? The
>> javax model API provides a (rather verbose) visitor approach as well as
>> method getKind() for this (so the latter is basically instanceof).
>>
>> --Gunnar
>>
>> [1]
>> http://docs.oracle.com/javase/8/docs/api/index.html?javax/lang/model/type/package-summary.html
>>
>>
>>
>>
>>
>>
>>
>>
>> 2014-06-03 12:51 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:
>>
>>>
>>> On 2 Jan 2014, at 18:36, Steve Ebersole <steve at hibernate.org> wrote:
>>>
>>> > 1) What do you think of the split in JavaTypeDescriptor into distinct
>>> > sub-contracts?  For example, the split between say ClassDescriptor and
>>> > InterfaceDescriptor?
>>>
>>> Didn’t we have this discussion before. If I remember correctly you were
>>> the one who favoured the
>>> current model. What made you change your mind.
>>>
>>> > TBH, I am starting to rethink that one.  What about
>>> > primitive versus non-primitive descriptors?  Etc…
>>>
>>> Unfortunately, I did not actually write code against the API yet, so I
>>> don’t have any concrete experience.
>>> On paper it looks good to me. But it seems you encountered something
>>> which creates an itch?
>>>
>>> > 2) Overall what do you think about the API itself?
>>>
>>> for what i have seen and what we discussed, it is the way to go. I can
>>> see me using this type of model
>>> in other Hibernate projects as well.
>>>
>>> —Hardy
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>