+1 Probably worth to check if we have dependencies that rely on Byte Buddy that can produce conflicts but I doubt it. My only worry was ASM leaking into the classpath, but it seems that Byte Buddy already shades ASM so that should not be an issue.
Ismaël On Thu, Mar 17, 2022 at 5:09 PM Liam Miller-Cushon <cus...@google.com> wrote: > > Hello, > > I wanted to raise the possibility of using the upstream version of bytebuddy > in beam, instead of vendoring it, from BEAM-14117. > > Vendoring the bytebuddy dep was introduced in BEAM-1019: > >> We encountered backward incompatible changes in bytebuddy during upgrading >> to Mockito 2.0. Shading bytebuddy helps to address them and future issues. > > > Vendoring makes it harder to upgrade the bytebuddy version, and upgrading > bytebuddy is one of the first things that needs to happen to support new Java > versions (e.g. BEAM-14065, BEAM-12241). > > Vendoring or shading bytebuddy is discouraged by the upstream owners of the > library, see e.g. https://github.com/assertj/assertj-core/issues/2470 where > assertj was migrated off a shaded version: > >> As Byte Buddy retains compatibility, not shading the library would allow >> running recent JVMs without an update of assertj but only BB. Other >> libraries like Mockito or Hibernate do not shade BB and there are no known >> issues with this approach. > > > Does anyone have additional context about the issues encountered during the > mockito 2.0 upgrade, or concerns with trying to unvendor bytebuddy? > > Thanks, > Liam
