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 Wed, Oct 12, 2016 at 3:36 PM Steve Ebersole <[email protected]> wrote: > oops, guess this works better if I send it to the group ;) > > > On Wed, Oct 12, 2016 at 1:09 PM Steve Ebersole <[email protected]> > wrote: > > 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 <[email protected]> wrote: > > I created https://hibernate.atlassian.net/browse/HHH-11152 to track this > > On Mon, Oct 3, 2016 at 6:55 AM Steve Ebersole <[email protected]> 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 <[email protected]> > wrote: > > 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 > retention. > > I try to find some time in the next two or three weeks and get back with a > prototype. > > Best regards, Rafael > > 2016-10-02 2:23 GMT+02:00 Steve Ebersole <[email protected]>: > > 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 <[email protected]> > wrote: > > 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ hibernate-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/hibernate-dev
