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

[Gunnar Morling]

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
>