[hibernate-dev] HHH-12353: have getReference stick to the Java API it promises?

[Steve Ebersole]

Sure, I think using DeprecationLogger is a good short-term option.


On Mon, Mar 5, 2018 at 9:32 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 5 March 2018 at 15:24, Steve Ebersole <steve at hibernate.org> wrote:
> > Fun trip down memory lane :)
> >
> > No one really like my proposed solution, but also no one really seemed to
> > dislike it enough to implement something themselves ;)
> >
> > Anyway, those older discussions are a piece of the same overall
> discussion
> > that this one belongs to.  This discussion is just a specific part of it.
> > Sanne and I both thought that the API should just accept the interface -
> we
> > just had different opinions about how that should work in mapping and in
> the
> > impl of the call.  Neither of our suggestions is spec compliant though.
> And
> > in this specific case I think (a) is the only real option
>
> Right, the JPA API doesn't leave much room to explore the alternatives
> we discussed in the past.
>
> What do you suggest we do now?
>
> In a nudge towards backwards compatibility it would be nice to start
> logging a bootstrap warning when a final class is being declared with
> such a proxy: we could warn about the inconsistent return that will
> happen at runtime, and would also be a good opportunity to warn we
> might remove support for such a tricky mapping altogether in a future
> release.
>
> And thanks Gunnar for finding the previous discussions, I had a vague
> idea we discussed this before :)
>
> Sanne
>
>
>
> >
> > On Mon, Mar 5, 2018 at 8:57 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >> Hey,
> >>
> >> It's just three and six years, respectively, since we discussed this
> >> matter
> >> last [1], [2] (wow, I'm feeling old somehow now ;)
> >>
> >> Detecting the situation at boot time and raising an exception early on
> >> would be the best.
> >>
> >> --Gunnar
> >>
> >> [1]
> http://lists.jboss.org/pipermail/hibernate-dev/2015-April/012520.html
> >> [2]
> >> http://lists.jboss.org/pipermail/hibernate-dev/2012-January/007629.html
> >>
> >>
> >> 2018-03-05 14:53 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> > Issue HHH-12353 was just reported and I have to agree it looks dodgy.
> >> >
> >> > Essentially invoking:
> >> >
> >> >  entityManager.getReference( Person.class )
> >> >
> >> > might not return a type compatible with Person, when Person is final
> >> > and annotated with @Proxy(proxyClass = AnotherTypeX.class), then
> >> > AnotherTypeX might be returned and this is not necessarily a subtype
> >> > of Person.
> >> >
> >> > That's ok as I understand we hardly have alternatives, but the
> >> > EntityManager API for getReference mandates this signature:
> >> >
> >> >  <T> T getReference(Class<T> entityClass, Object primaryKey)
> >> >
> >> > so we're not actually returning the expected type T in all
> >> > circumstances, confusing compilers and tooling into giving the wrong
> >> > suggestions.
> >> >
> >> > I see some options:
> >> > a# disallow using @Proxy on a final entity - seems reasonable since
> >> > the docs warn against pitfalls.
> >> > b# throw an exception on Person.class being used as parameter, as the
> >> > user should actually use the proxytype?
> >> > c# somehow have the proxy still extend the final entity?
> >> >
> >> > Option b# seems problematic as it's not obvious to users either, and
> >> > we would need to return a proxy reference even when there actually is
> >> > a managed Person instance in the current session.
> >> >
> >> > Option c# is probably unrealistic and problematic too, as it would
> >> > require enhancing of the final class and I guess we can't rely on that
> >> > consistently.
> >> >
> >> > In summary, I believe we should throw a bootstrap exception requiring
> >> > to remove the `final` modifier on the parent entity. Or challenge the
> >> > specification :(
> >> >
> >> > Thanks,
> >> > Sanne
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>