Noticed that an lazily-loaded entity was getting a ClassCastException inside the proxy method without any explicit casting in the application code. I've pared down the issue to a minimal example and attached a FunctionalTestCase. See:
This is clearly related to "the dreaded proxy problem" with its variety of solutions/workarounds(http://community.jboss.org/wiki/ProxyVisitorPattern) but in those cases the application code makes a mistaken assumption that it can downcast a proxy. In this example, there is no explicit downcasting, although I suppose SubClass.toSubClass() could be considered "implicit downcasting". Within SubClass, "this" must refer to an instance of SubClass, and it presumably should be returnable as such.
I haven't checked what's going on in the proxy code, but I presume that it sees that it is trying to return the item corresponding to the proxy itself, and attempts to return that proxy. However the proxy is not an instance of SubClass and there is a ClassCastException.
I'd suggest one of the following solutions:
have the proxy return the unproxied (already initialized) object if it cannot cast it appropriately
have the proxy re-proxy the already initialized object into an instance of the appropriate class
have some explicit documentation as to why this cannot be expected to work and why domain classes need to avoid this behavior.
In any case it seems poor that even improperly written entity code can cause an exception inside the proxy-specific code.
Hibernate version 3.6.6
Windows 7 and Linux
CGLib and javassist