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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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(a)hibernate.org&gt;: > 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(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

On 5 March 2018 at 15:24, Steve Ebersole <steve(a)hibernate.org&gt; 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(a)hibernate.org&gt; 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(a)hibernate.org&gt;: >> >> > 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(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