2:17 a.m.
Hi,
I think that's a great idea
Same here!
Another advantage is we separate the "SPI"/internal interface (Handler)
from the API that can be implemented by users (listeners).
That could be a great help moving forward to evolve Hibernate ORM without
breaking APIs.
but I wonder about the readability of the code.
I was thinking that it was actually *more* readable. Maybe it's just a
matter of taste, but this:
Object loaded = handler.load( param1, param2, ... )
Seems considerably more straightforward than this:
LoadEvent event = new LoadEvent( param1, param2, ... )
for (LoadListener listener: listeners) {
listener.onLoad( event );
}
Object loaded = event.getLoaded();
Especially if you consider that with the handler, the implementation of
loading is just one CTRL+click away.
With listeners you have to go through all the listener implementations and
find which one actually implements loading.
Not a problem with load since there's only one implementation, but I know
I've had trouble with other events in the past.
The devil is in the details, though. I admit it could get more complex if
multiple return values are necessary, and maybe there are other problems
with this approach that we can't see right away.
But still, I think it's worth a try.
With "inline types" coming soon to the JDK, the event
object
types could be great candidates to be converted into inline?
Aren't you talking about JDKs that we won't be able to use as the baseline
for Hibernate ORM for a few years at least? If so, Steve's change seems
worthwhile, if only in the meantime.
Yoann Rodière
Hibernate Team
yoann(a)hibernate.org
On Tue, 26 May 2020 at 20:17, Sanne Grinovero <sanne(a)hibernate.org> wrote:
Hi Steve,
looks like you're getting rid of the "event object"? No more events to
be allocated?
I think that's a great idea, but I wonder about the readability of the
code. With "inline types" coming soon to the JDK, the event object
types could be great candidates to be converted into inline?
If we used the inline types for such things I'm confident that
allocation would improve significantly; it's undeniable that not
having anything-at-all would be even better - but perhaps it could be
a better tradeoff in consideration of maintainability.
I also noticed that it's quite possible that some "list of
eventlisteners" for a specific event type could be empty: no listeners
at all.
So an aspect that could be worth exploring while thinking about the
event system design, is to avoid creating en event in such cases;
there's an example of this approach already in
org.hibernate.internal.SessionImpl#internalClear : the signature I had
to use is a bit puzzling, but it manages to avoid allocating the event
(unless needed) and also avoids allocating the iterator on the
listeners.
For example PostLoad events by default have a single listener, but
looking more closely I believe we could avoid registering that single
listener depending on configuration.
Thanks,
Sanne
On Tue, 26 May 2020 at 16:00, Steve Ebersole <steve(a)hibernate.org> wrote:
>
> Historically we made a terrible design mistake with the event system as a
> whole. This has both a confusing design impact and a very real
performance
> impact. The main problem is the smashing together of things that handle
> events and things that listen to such events.
>
> In working on a problem in v6 I have come to a point where fixing this
> design flaw for load events specifically would be a huge help. So I'm
> going to make a proposal for how to specifically change this for load
event
> handling. The plan at the moment is to not make similar changes to the
> other event types for now, though I certainly would like to keep them all
> in mind with regard to the overall design for if/when we can get to the
> others.
>
> So I'd love feedback specifically regarding (1) general design
considering
> other event types and (2) issues/concerns specific to load event type.
>
> I created a simple example at
> https://gist.github.com/sebersole/2a1c3ac010a166fc91e62b088179678d
>
> Thanks!
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev