2014-06-03 15:44 GMT+02:00 Steve Ebersole <st...@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 <gun...@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 <ha...@hibernate.org>: >> >>> >>> On 2 Jan 2014, at 18:36, Steve Ebersole <st...@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@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
