Introducing our own API doesn't make much sense to me. The challenges (support for new unknown Java versions) would be exactly the same as ASM has. So we would in the end also be forced to break the API :( Remember that the main reason we created the whole shading for is to allow to upgrade parts of the stack without interfering with a.) some custom apps and b.) each other.
Right now you can just swap out openjpa in TomEE for example. All you need to do is to _potentially_ also add another xbean-asm version. And that is good that way imo. LieGrue, strub > Am 01.10.2018 um 14:12 schrieb Romain Manni-Bucau <[email protected]>: > > > > Le lun. 1 oct. 2018 à 12:39, Mark Struberg <[email protected]> a écrit : > We should analyse if ASM7 is a drop-in replacement and can be used in a > backward compatible way. > > Didn't review everything but there are some changes in the impl which are not > compatible and why we must upgrade even if asm 6.2.1 had some good java 11 > support. > > If so, then we could keep the shaded o.a.g.asm6 package and just document it. > > I thought about it but it sounds so dangerous and hard to control on the long > run than upgrading all our stack sounds worth it for me. > > If ASM7 removed some old methods, then we really should also shade to a > private asm7 package. > > This lead to the option to not expose ASM at all and create our own API but > it breaks the reason why all our stack uses this shade: have a fully featured > ASM usable by proxying impl of the full stack > and share it with the scanner. This is why I thought we can't really fake the > package without serious risk, we expose a too big coverage now (cxf, openjpa, > xbean, big data engines, user apps, ...). > > > LieGrue, > strub > > > > Am 30.09.2018 um 19:44 schrieb Romain Manni-Bucau <[email protected]>: > > > > Hi guys, > > > > Asm 7 beta was released yesterday, I'd like to try to release it ASAP. > > I see 1 main point to discuss before releasing: do we keep the version in > > the package and module name? For now it is required cause we cant guarantee > > anything about asm compatibility. > > > > Options I see are: > > 1. drop asm and use bcel (which is asf) > > 2. drop asm and reimplement bytecode parsing for our need (but will create > > issue in most of our stack for proxy creation IMHO) > > 3. keep it like that > > 4. use an "asm.*" package crossing fingers > > > > I'd love 4 but I fear it can create issue quickly when I see what java is > > becoming so, personally, i think 3 is safe but since we are at "that" > > moment I'd like to get your feedback. > > > > Side note: if I get no other vote than 3 before tuesday, i'll try to launch > > the release on tuesday with asm7 module and package to let us get it out. > > > > Romain Manni-Bucau > > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >
