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.
In a shared containerized environment like Travis, it's not obvious that
the second read will be faster than the first one.
And indeed, the test often fails.
There's no real value in testing that, we are just testing I/O, and the OS
cache.
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.