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 <st...@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 <st...@hibernate.org>
> 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 <st...@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 <st...@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....@gmail.com>
> 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 <st...@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....@gmail.com>
> 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
> 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

Reply via email to