[hibernate-dev] Introducing a "none" BytecodeProvider

[Sanne Grinovero]

On Thu, 18 Oct 2018 at 07:39, Yoann Rodiere <yoann at hibernate.org> wrote:
>
> Can't say if it's a good or bad idea, but if you don't document it in the user guide, please at least document how dangerous it is and why it can be useful in the source code where the "none" option appears. I expect some users will find it while debugging, try it out to solve their problems or maybe just "to improve performance" and will have a bad experience... Not to mention ourselves in a few weeks, of course :)

+1
It's not terribly dangerous as it's going to throw very explicit
exceptions on misconfiguration. But I agree, and because of those same
concerns is that we're having this thread.

I'm thinking of it as a slighly experimental thing which does no harm
in being merged, as it's entirely isolated by a "feature flag".

> Regarding "BasicProxyFactory", Guillaume and I had to fight with this think a few weeks ago, I think. If I remember correctly, it's used in particular to instantiate abstract classes (!) during bootstrap. It seems to be needed when copying data around from an object to another in particular; maybe when the type of an @Embedded property is abstract? Someone else probably knows more. All I can say is it made some tests fail some time ago, so you can try making it throw exceptions and run the tests that fail in debug mode, to see why it's useful exactly.

Thanks for the hint.

I had found some similar clues, and I'm thinking to just limit its
applicability to models which don't have similar needs: in a second
phase we could look at creating the necessary bytecode to handle these
corner cases as well by having the build time enhancement generate the
additional support classes.

>
>
> Yoann Rodière
> Hibernate NoORM Team
> yoann at hibernate.org
>
>
> On Wed, 17 Oct 2018 at 19:47, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> After some experimentation I figured out that the BytecodeProvider is
>> not really necessary, if you are happy to use the tools we have to
>> enhance the entities upfront.
>>
>> In some environments such as on GraalVM I need to pre-enhance the
>> entities (need as in "not optional"), but some further things would be
>> really much simpler if I then could exclude Byte Buddy from runtime
>> dependencies.
>>
>> As the code stands today, the Byte Buddy engine is loaded very early
>> during bootstrap (even if the entities are already enhanced, as we
>> didn't test for that yet at this point) and can't be disabled.
>>
>> I have a successful experiment which introduces a "none" configuration
>> value for the "hibernate.bytecode.provider" property which allows me
>> to fully disable the need to have ByteBuddy on classpath at runtime.
>>
>> I would not generally recommend this as there is no safety net: if you
>> set this property AND did not enhance your entities, I expect trouble.
>>
>> Also there's a strong limitation: I could not implement the
>> `BasicProxyFactory`, which is probably making this unfit for general
>> purpose; I could use some help to nail down why exactly we need this
>> and see if we can actually implement an alternative - possibly having
>> the build time entity enhancement tools generate the necessary
>> bytecode upfront?
>>
>> Still, I'd propose to merge this feature as an advanced feature that
>> some power users will need when making progress on support for new
>> platforms. Because of this experimental aspect, I'm not bothering to
>> mention it on the user guide :)
>>
>> Ok?
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev