Re: [hibernate-dev] Support for entities without default constructor

[Gunnar Morling]

> The avoidance of reflective constructor invocation via byte code
generation should be rather simple using ByteBuddy.

Turns out that the ByteBuddy byte code provider already has an
instantiation optimizer doing exactly that [1]. Unfortunately, though, from
what I can say it's never used due to a bug in PojoEntityTuplizer which
ignores the reflection optimizer's instantation optimizer. I've logged
HHH-12284
[2] for that.

--Gunnar

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/bytecode/internal/bytebuddy/BytecodeProviderImpl.java#L61-L74

[2] https://hibernate.atlassian.net/browse/HHH-12284


2018-02-04 12:30 GMT+01:00 Gunnar Morling :

> 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 :
>
>> 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 
>> 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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Support for entities without default constructor

[Gunnar Morling]

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 :

> 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 
> 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev