BTW, I did go back and verify that indeed the mismatch is with
@Proxy.proxyClass specifying an interface. Consider an example:
@Entity
@Proxy(proxyClass=User.class)
public class UserImpl implements User {
...
}
You will never be able to cast proxies instance of this thing to
UserImpl. This call will fail with CCE:
UserImpl u = (UserImpl) session.load( UserImpl.class, ... )
get() may or may not work depending.
This is the source of us not being able to offer generic signatures.
On Wed 25 Jan 2012 01:33:14 PM CST, Steve Ebersole wrote:
> In regards to the new "load access", a user asked why we don't
> leverage generics.
>
> The problem is the existence of @Proxy#proxyClass. We have the same
> issue with Session#load/get taking the entity Class. We can't use a
> generic sig like:
>
> public <T> T load(Class<T> entityType, ...)
>
> because at times we return objects that are not typed to <T>. I have
> to dive back into the specifics, but IIRC the problem is that we don't
> do the expected thing and have the generated proxy class extend from
> the entity class if @Proxy#proxyClass names an interface. I remember
> this change way back when, but the specifics of why escape me at the
> moment.
>
> IMO I think providing generic signatures would obviously be a great
> improvement. Is it enough to change this behavior?
>
> WDYT?
>
--
st...@hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
