2014-06-03 15:44 GMT+02:00 Steve Ebersole <steve(a)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(a)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...
>
>
>
>
>
>
>
>
> 2014-06-03 12:51 GMT+02:00 Hardy Ferentschik <hardy(a)hibernate.org>:
>
>>
>> On 2 Jan 2014, at 18:36, Steve Ebersole <steve(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>