11:36 a.m.
I am curious about people's take on "reflite" now that some of y'all
have
had a chance to see it in action.
Some specific points I am curious about (although certainly feel free to
comment on any parts):
1) What do you think of the split in JavaTypeDescriptor into distinct
sub-contracts? For example, the split between say ClassDescriptor and
InterfaceDescriptor? TBH, I am starting to rethink that one. What about
primitive versus non-primitive descriptors? Etc...
2) Overall what do you think about the API itself? Don't worry about the
internal details. For example, the need to access the ClassLoader (to walk
the fields/methods) is hopefully going away with some additions to Jandex.
But in terms of the exposed contracts
(org.hibernate.metamodel.reflite.spi)...
5:51 a.m.
On 2 Jan 2014, at 18:36, Steve Ebersole <steve(a)hibernate.org> wrote:
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
8:09 a.m.
Not exactly sure what you mean by "favoured" it. I'm the one who wrote it
all for sure, if that's what you mean. But I was just trying something.
The java.lang.Class model has pros and cons to it. I had just wanted to
investigate alternative models to see whether those pros/cons could be
improved.
The point is that this isn't just my call (imo). It should be a consensus.
If no one else had played with it enough to have an opinion then that is a
different deal. Here are my thoughts, and maybe we can all discuss the
generalities.
So the ubiquitous nature of java.lang.Class is both a pro/con. To that
model classes, interfaces, arrays, primitives all look the same. That's
great for some things (generalized algorithms: e.g. walk hierarchies), but
lacking for others.
I guess the conclusion I came to was that I am not sure if the split model
currently in reflite gains enough to offset the unique model. What I mean
is that if reflite followed a java.lang.Class-like paradigm for defining
the model, then there is a certain parallel familiarity when people first
come into reflite code.
On Tue, Jun 3, 2014 at 5:51 AM, Hardy Ferentschik <hardy(a)hibernate.org>
wrote:
8:33 a.m.
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>:
8:51 a.m.
2014-06-03 15:44 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
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:
3940
days inactive
3942
days old
7 comments
4 participants
participants (4)
-
Gail Badner -
Gunnar Morling -
Hardy Ferentschik -
Steve Ebersole