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

[Steve Ebersole]

+1 (a) is the only feasible option


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

> 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
>