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.
Considering hibernate-orm-modules tests are disabled with JDK 11, it's
safer to prevent us from running a release with it. And all in all, we'd
better release with JDK 8.
We don't have the certainty that we don't use Asciidoctor Javadoc but
using Asciidoclet leads to malformed Javadoc if we are using HTML
Javadoc, which concerns the high majority of our files.
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.
Yoann Rodière
Ulrich Bestfleisch
Guillaume Smet
Gail Badner
Vlad Mihalcea
Sanne Grinovero
Jonathan Bregler
Fabio Massimo Ercoli
Diego Lovison
Galder Zamarreño
Robert Rettig