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.
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
>