regarding more human-friendly table alias
by Nathan Xu
My point might have been discussed previously. I beg your pardon if my message bothers you.
As everybody knows, Hibernate will create very terse and mystic table alias. I often feel frustrated by them when trying to read the SQL Hibernate has produced. There must be many thoughts behind its current design, I think. Could we achieve the goal to avoid sacrificing SQL readability while having our job done? Needless to say, experienced Hibernate user still needs to understand the auto-generated SQL for many reasons (troubleshooting, optimization), and a human-friendly SQL might make for a far better user experience.
In terms of implementation, we can simulate human's thinking process when designing a table alias (TBH, sometimes even human is frustrated to think of a most satisfying alias). Many heuristics could be applied (e.g., hufman encoding algorithm) and it would be a good selling point for v6.
Any thoughts? Again, pardon me if the point has been discussed previously.
4 years, 4 months
Regarding lazy initialization of ArrayList
by Nathan Xu
This is my first message posted here after I finally succeeded in
subscribing to Hibernate dev mail list.
As well known, we utilized the following 'lazy initialization' pattern
extensively in our codebase to save memory:
if ( activeFactoryNames == null ) {
activeFactoryNames = new ArrayList<>();
}
However, even since JDK7, ArrayList has gone through refactoring to
keep from allocating
memory for 10 elements in advance, if the instance was created by
default constructor and the allocation of memory
is only done when some element is really added in future. Namely,
ArrayList has the lazy initialization feature built-in.
E.g., see https://stackoverflow.com/questions/33688753/jdk-api-documentation-is-inc...
for details. You can also browse the source code of ArrayList to confirm.
[image: Screen Shot 2020-08-18 at 4.06.58 PM.png]
Needless to say, the lazy initialization pattern has serious NPE issue
if it is not coded carefully (which is tedious and error-prone per
se).
As an active Hibernate v6 contributor, I am troubled by such NPE issue
again and again.
Is it a good timing to get rid of the above lazy initialization pattern for now?
Hopefully my message is good food for thought. No finger pointing. Just curious.
4 years, 4 months
Dropping support for Java 8 in Hibernate ORM (Search) v6 ?
by Sanne Grinovero
Hi all,
[meta: I had this email as a draft on hold since a year; very glad to
finally be able to send it.]
We're usually quite conservative in dropping support for older JDKs
within the Hibernate team, but there's an increasing maintenance (and
development) cost when keeping older JDK compatibility for too long.
In particular, Java 8 compatibility was so far still a requirement for
various strategic integrations; first, we had runtimes targeting
GraalVM still needing it, but they support Java 11 now as well; after
that, Azure Functions were also still requiring Java 8, but this
limitation was resolved now.
We're aware that Java 8 is still widely used; still I think we need to
look forward - for various reasons, including maintenance burden, and
to deliver a better experience on the later versions of the JDK. Also,
looking at the existing usage statistics implies a fallacy: that's
current production usage, while the code we normally work is
(typically) not going to see production usage for quite some time.
While we'll want to keep Java 8 compatibility for existing
[maintained] releases, there is no compelling reason anymore to keep
doing this for the upcoming major releases.
So I'd propose we require Java 11 the minimum compatible runtime for
ORM v6 onward, and I'd suggest we do the same with all our actively
developed projects.
Initially, I don't really expect this to significantly increase the
efforts from our already packed roadmaps: in the first stage this
proposal is literally only about making minimal changes to our build
scripts to change the compatibility versions, and for CI to stop
testing the JDK/branches combinations which are no longer supported.
In a second step, as convenient, we'll be able to:
- do some code cleanup / refactorings to benefit from the minor API
improvements of the JDK
- some APIs had more substantial improvements, such as java.sql now
features native support for multi-tenancy, literals and identifiers
enquoting [among others] .. might be interesting.
- finally benefit from Jigsaw?
Any thoughts?
Thanks,
Sanne
4 years, 4 months
Bad boot performance since 5.4 switched to ByteBuddy
by Christian Beikov
I'm moving this discussion from Zulip to the mailing list as Rafael does
not seem to be on Zulip. Here a little context:
> Does anyone know if there is a known performance issue with Bytebuddy
during boot in 5.4? I noticed that 5.4 takes about 25%, sometimes up to
30% percent longer to boot, even when using a prebuilt Jandex index,
apparently due to the use of Bytebuddy
> @Moritz Becker found the issue while trying to find out why our
Blaze-Persistence testsuite runs into CI timeouts with 5.4 but not with 5.3
> So AFAIK, the PojoEntityTuplizer builds the proxy class through
org.hibernate.proxy.pojo.bytebuddy.ByteBuddyProxyHelper#buildProxy which
takes significantly longer than the javassist implementation
I haven't tried it yet, but it seems to me that making the
byteBuddyState in
org.hibernate.bytecode.internal.bytebuddy.BytecodeProviderImpl static
might help. I'd guess this will help with the test execution time for
the Hibernate testsuite as well.
Any idea how to improve this @Rafael ?
Regards,
Christian
4 years, 4 months
