[hibernate-dev] Reflite

[Gunnar Morling]

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
>