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.
2018-02-04 8:34 GMT+01:00 Vlad Mihalcea <mihalcea.v...@gmail.com>:
> For anyone interested, Josh Long tell more about why they took this
> approach where they inject the default constructor:
> Rafael Winterhaler shows that this can be easily done with Byte Buddy which
> we already used before:
> 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?
> On Sat, Feb 3, 2018 at 5:03 PM, Vlad Mihalcea <mihalcea.v...@gmail.com>
> > 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 mailing list