I like it, but I think that's two separate concerns:
* using byte code generation to improve performance of entity instantiations
* avoiding the need for entities to have a parameterless constructor,
emphasising the mandatory properties of an entity (by requiring them as
constructor parameters) and allowing read-only entities to be truly
immutable (i.e. with final fields)
Both can be addressed independently.
The latter seems more impactful for developer experience, the need for a
default constructor has been a long-standing point of criticism often
raised by DDD-minded folks. As said on Twitter, it'll likely require an
annotation to mark the "persistence constructor", i.e. the one to be called
by Hibernate in case there are multiple ones. And we need a mapping between
parameter names and entity property names. That's "for free" if parameter
names are part of the byte code as possible with the "-parameters" option
in javac 8, otherwise some help by the developer is needed.
The avoidance of reflective constructor invocation via byte code generation
should be rather simple using ByteBuddy.
--Gunnar
2018-02-04 8:34 GMT+01:00 Vlad Mihalcea <mihalcea.vlad(a)gmail.com>:
For anyone interested, Josh Long tell more about why they took this
approach where they inject the default constructor:
https://twitter.com/starbuxman/status/960049941916696578
Rafael Winterhaler shows that this can be easily done with Byte Buddy which
we already used before:
https://twitter.com/rafaelcodes/status/959892398997458946
If we can prove that it's indeed significantly faster than using Java
Reflection to build entities,
I think we should think about taking this approach as well.
What do you think of this?
Vlad
On Sat, Feb 3, 2018 at 5:03 PM, Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
wrote:
> Hi,
>
> I realized that we could allow users to define entities without a default
> constructor.
>
> For Kotlin, which supportsdefault values, this could be beneficial.
>
> There is some info about how we could do that in this using Objenesis in
> the following Spring issue:
>
>
https://jira.spring.io/plugins/servlet/mobile#issue/SPR-10594
>
> Let me know what you think,
> Vlad
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev