Sure, I think using DeprecationLogger is a good short-term option.
On Mon, Mar 5, 2018 at 9:32 AM Sanne Grinovero <sa...@hibernate.org> wrote: > On 5 March 2018 at 15:24, Steve Ebersole <st...@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 <gun...@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 <sa...@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@lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
