-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
HHH-18976 Avoid usage of Array.newInstance #9569
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…Array#newInstance
…lans It's more consistent, and happens to get rid of ArrayMutabilityPlan, which involved an unnecessary use of Array.newInstance. I've also seen claims that clone() performs better than Array.newInstance() due to not having to zero-out the allocated memory, but I doubt that's relevant here.
No functional impact, it's just less redundant.
…e type descriptors
… to new Object[] The dynamic instantiations were originally introduced to fix the following issues: * HHH-16466 (initial support for array parameters in multi-key loads) -- tested in MultiLoadTest * HHH-16750 -- tested in CompositeIdWithOneFieldAndElementCollectionBatchingTest * HHH-17201 -- tested in MultiIdEntityLoadTests The corresponding tests still pass after removing these dynamic array instantiations.
|
Hey @sebersole @beikov, this might be of interest to you. I'm still waiting for the full CI run -- I personally only ran tests in a few relevant test packages. But assuming tests pass, I think merging this would make HHH-16809 / #6815 mostly irrelevant... A EDIT: FWIW: HHH-18976...HHH-16809. It's unfinished, I didn't implement |
|
So I thought this, given the implementation of H2Dialect, meant arrays were in use for H2 as well: Line 859 in 0a2c229
But apparently they are not, so the successful tests I had locally were meaningless and I need to test on postgres specifically. Back to the drawing board... EDIT: hibernate-orm/hibernate-core/src/main/java/org/hibernate/dialect/H2Dialect.java Lines 199 to 203 in 928799d
|
|
Closing, will submit another PR with a more conservative solution. |
https://hibernate.atlassian.net/browse/HHH-18976
Two things in here:
Array.newInstance(and util methods known to use it) by default. This is mostly as a heads-up to not use it "just because", since the check can be bypassed if necessary by annotating the method with@AllowReflection.Array.newInstance. E.g.:array.clone()where relevant (i.e. when we want the same array type with the same length).Array.newInstancejust to retrieve theClassof an array type -- since we ultimately just look use thatClassto look up a descriptor in a registry.new Object[...]instead where possible (e.g. when the array ends up being used internally only).This should get rid of most problematic uses of reflection when compiling to native binaries (see Jira issue).
There are still a few uses of
Array.newInstancebut as far as I can see they are completely justified and cannot easily be worked around: array mapping, JSON/XML serialization, instantiation of query result types, ...