[hibernate-dev] Adding a Byte Buddy byte code provider to Hibernate
steve at hibernate.org
Wed Oct 12 16:36:40 EDT 2016
Since this is gaining some traction, I think we need to start deciding:
1. whether to have Byte Buddy *replace* Javassist, or to have it as an
2. IIUC some of our issues could be alleviated by generating a Javassist
shaded jar. Should we consider that for Byte Buddy out the gate?
On Wed, Oct 12, 2016 at 3:36 PM Steve Ebersole <steve at hibernate.org> wrote:
> oops, guess this works better if I send it to the group ;)
> On Wed, Oct 12, 2016 at 1:09 PM Steve Ebersole <steve at hibernate.org>
> Since this is gaining some traction, I think we need to start deciding:
> 1. whether to have Byte Buddy *replace* Javassist, or to have it as an
> alternative impl
> 2. IIUC some of our issues could be alleviated by generating a
> Javassist shaded jar. Should we consider that for Byte Buddy out the gate?
> On Tue, Oct 4, 2016 at 9:18 AM Steve Ebersole <steve at hibernate.org> wrote:
> I created https://hibernate.atlassian.net/browse/HHH-11152 to track this
> On Mon, Oct 3, 2016 at 6:55 AM Steve Ebersole <steve at hibernate.org> wrote:
> I'd also like to revisit the BytecodeProvider contracts. I wrote those
> really to fit CGLIB and Javassist and our legacy code around CGLIB
> specifically. But I'd like to revamp that to be more logical. So feel
> free to suggest any edits to the SPI that you feel make sense.
> We should also decide if we want to support both, or just move to
> ByteBuddy. If we support both, we will not be able to leverage things
> that ByteBuddy can do that Javassist cant (like you mention annotation
> retention). Personally I think we should just pick one and go with it.
> I can't imagine users generally care. However I do think the SPI still has
> merit as it makes it easier to experiment with alternatives/replacements
> later (as it made it easier for you here).
> On Mon, Oct 3, 2016, 6:43 AM Rafael Winterhalter <rafael.wth at gmail.com>
> Hi Steve,
> it is great to hear you are interested! By "proof of concept" I mean that
> I have not yet put much effort into it as I did not know if this was an
> option at all. I only wrote a very general implementation without testing
> it to see if there is anything missing in Byte Buddy that Javassist is
> offering and that you relied upon. Byte Buddy makes a few things different
> when it comes to manipulating existing code but this is not in the scope of
> what Hibernate is currently using Javassist for.
> I am more than happy to write a real BytecodeProvider using Byte Buddy. In
> a first step, I would simply mimic the current Javassist provider. In a
> later step, I would then try to apply a few optimizations to make the
> interceptor a bit more lean; this would benefit performance due to on
> inlining size and make it easier to debug. At this stage, we can also look
> into a few features that Javassist does not offer as for example annotation
> I try to find some time in the next two or three weeks and get back with a
> Best regards, Rafael
> 2016-10-02 2:23 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> That's awesome that you were able to code something up Rafael. I will set
> aside some time next week to look this over.
> When you say "proof of concept" I am curious how complete you feel this
> is. You mentioned not dealing with the fast-class stuff, which is ok by me
> - as you say, this is not so much an issue anymore as it was back in JDK
> 1.4 :) More I mean in terms of both proxy generation support and bytecode
> enhancement. In regards to those 2, how complete do you feel this work is?
> And again, thanks for taking this on. This is something I have wanted to
> look at, but just could never find the time. Glad someone took this on.
> On Sat, Oct 1, 2016 at 10:25 AM Rafael Winterhalter <rafael.wth at gmail.com>
> Hello everybody,
> I was wondering how big the chances are to get a Byte Buddy bytecode
> provider into Hibernate? Byte Buddy has matured a lot over the last two
> years and it aims a lot on performance what is something Hibernate could
> benefit of. There are comparion charts posted on the Byte Buddy webpage. As
> a bonus, Byte Buddy is already ready for Java 9 and gives a lot of features
> for free, for example generic meta data retention and a possibility to
> retain annotations on subclassed types and overridden methods.
> I have written a simple proof of concept here:
> https://github.com/raphw/hibernate-bb without having tested it - I did not
> implement the fast class providers as I have learned after a lot of
> benchmarking that those do not improve performance on Java 8+ VMs anymore.
> Using such fast-classing rather pollutes the code cache than bring any
> benefit. The only advantage with code generation in this field comes when
> avoiding boxing what is not the case. But of course, I can implement
> something in Byte Buddy to apply such a fast-class mechanism.
> Let me know what you think. I am more then happy to help you with
> implementing such a provider. Other frameworks such as Mockito already use
> Byte Buddy on a large scale and made good experiences with it.
> Best regards, Rafael
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
More information about the hibernate-dev