6:36 p.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)...
7:47 p.m.
Hi Steve,
I haven't had much of a chance to use it yet, but I like what I've seen so far.
When I get back to Envers (later this week), there are places that use the Jandex index
that I will change to use reflite. I'll have more feedback then.
Gail
----- Original Message -----
From: "Steve Ebersole" <steve(a)hibernate.org>
To: "hibernate-dev" <hibernate-dev(a)lists.jboss.org>
Sent: Monday, June 2, 2014 9:36:09 AM
Subject: [hibernate-dev] Reflite
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)...
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
10:46 p.m.
What do you think about collapsing these into a single spi contract, rather
than broken out (e.g., more akin to jdk reflection)? Specifically in
regards to ClassDescriptor and InterfaceDescriptor
On Mon, Jun 2, 2014 at 12:47 PM, Gail Badner <gbadner(a)redhat.com> wrote:
Hi Steve,
I haven't had much of a chance to use it yet, but I like what I've seen so
far. When I get back to Envers (later this week), there are places that use
the Jandex index that I will change to use reflite. I'll have more feedback
then.
Gail
----- Original Message -----
> From: "Steve Ebersole" <steve(a)hibernate.org>
> To: "hibernate-dev" <hibernate-dev(a)lists.jboss.org>
> Sent: Monday, June 2, 2014 9:36:09 AM
> Subject: [hibernate-dev] Reflite
>
> 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)...
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
12:51 p.m.
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
3:09 p.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:
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
3:33 p.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>:
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
3:44 p.m.
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
>
3:51 p.m.
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
>>
>
>
3614
days inactive
3616
days old
7 comments
4 participants
participants (4)
-
Gail Badner -
Gunnar Morling -
Hardy Ferentschik -
Steve Ebersole