While Javassist only generates one proxy as the name is stable,
ByteBuddy uses random names and thus generates a new proxy for every
call, leading to the generation of 18 different proxies for the other
test of the test class.
We can't do better than using a volatile/synchronized pattern as the
Component is not fully initialized in the constructor.
Maybe we could take the risk of admitting that the getType() method is
called at least once before we pass the element to a multi-threaded
environment but that's a bet I don't want to take alone.
Bytecode enhancement is harder to test, so I didn't add a test for that,
but since bytecode enhancement dirty checking is called exactly at the
same place, if one works, the other should, too.
SessionImpl.initQueryFromNamedDefinition calls its super implementation
AbstractSharedSessionContract.initQueryFromNamedDefinition, which
already does a lot of the work performed in
SessionImpl.initQueryFromNamedDefinition.
The only difference is that SessionImpl uses hints to set values on the
query, whereas AbstractSharedSessionContract uses direct calls to
setters. But that should produce the same result, since setHint() just
delegates to the setters.
Only one thing was done in SessionImpl but not in
AbstractSharedSessionContract: lock mode handling.
I left it in SessionImpl since moving it to the superclass would also
affect other subclasses such as StatelessSession or OGM sessions, and I
certainly don't want to change any behavior without further
investigation.
Apart from cosmetic changes, we were testing in the equals() method that the
instance == the proxied object which will always be true.
We should use the argument of the equals() method instead to do the
comparison.
And we can do the comparison on the instance, instead of requiring
passing the proxiedObject into the interceptor.
I did not mark ParameterRegistration as incubating, because it's a
pre-existing interface that we can't reasonably consider as incubating.
It's a bit odd to have a non-incubating contract (ParameterRegistration)
extend an incubating one (ProcedureParameter), though...
In theory, trying to deserialize MapLazyInitializer instances that were
serialized before this patch should still work, although using such
instances (i.e. trying to access any method on the proxy) would still
fail, just like it used to before this patch.
If we copy the behavior of "traditional" (non-map) proxies to the
"dynamic-map" proxies, we'd better know what this behavior is and be
sure it works correctly.
A no-arg constructor is only necessary for superclasses of serializable
classes that are not themselves serializable. Here the class is
serializable, so the constructor is useless.
Guillaume Smet
Chris Cranford
Martin Simka
Yoann Rodière
Ulrich Bestfleisch
Gail Badner
Vlad Mihalcea
Fabio Massimo Ercoli
Robert Rettig