On Thu, 18 Oct 2018 at 07:39, Yoann Rodiere <yo...@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 > yo...@hibernate.org > > > On Wed, 17 Oct 2018 at 19:47, Sanne Grinovero <sa...@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@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
