FYI, here's a diff of the API https://gist.github.com/rotty3000/a68c8ea494f4c1b2e304822dc8a72a66
It doesn't look that scary tbh. Only couple methods changed which were already marked experimental and just normalized into the regular API, same for a couple of constants, and one other method removed and exploded into 3. Hope this helps, - Ray On Mon, Oct 1, 2018 at 9:39 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > @Raymond: no worries -> > http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-asm7-shaded/ > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le lun. 1 oct. 2018 à 15:37, Raymond Auge <raymond.a...@liferay.com> a > écrit : > >> Sorry for the newbie interruption. But can someone point me to the >> relevant code/project/module in Geronimo that has this asm integration? >> >> Thanks, >> - Ray >> >> On Mon, Oct 1, 2018 at 8:30 AM Romain Manni-Bucau <rmannibu...@gmail.com> >> wrote: >> >>> >>> >>> >>> Le lun. 1 oct. 2018 à 14:26, Mark Struberg <strub...@yahoo.de> a écrit : >>> >>>> Introducing our own API doesn't make much sense to me. >>>> >>> >>> Agree cause it is not just an xbean internal >>> >>> >>>> The challenges (support for new unknown Java versions) would be exactly >>>> the same as ASM has. >>>> >>> >>> It wouldn't if we would be in asm scope cause we would use a very >>> limited set of asm features. We are kind in a situation where we use 10% of >>> the features and expose 100% by construction :(. >>> >>> >>>> 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. >>>> >>> >>> Agree. >>> >>> >>>> >>>> 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. >>>> >>> >>> Ok so you confirm keeping the pattern we use (ie going with asm7) is ok >>> for you? >>> >>> FYI the diff: >>> https://gitlab.ow2.org/asm/asm/compare/ASM_6_2_1...ASM_7_0_BETA >>> But some impl changes are not just fixes and even if signatures don't >>> always change I think it is sane to not put a v7 in an asm6 package/module >>> - same as for java 8 upgrade where the verifier was stricter. >>> >>> >>>> >>>> LieGrue, >>>> strub >>>> >>>> > Am 01.10.2018 um 14:12 schrieb Romain Manni-Bucau < >>>> rmannibu...@gmail.com>: >>>> > >>>> > >>>> > >>>> > Le lun. 1 oct. 2018 à 12:39, Mark Struberg <strub...@yahoo.de> 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 < >>>> rmannibu...@gmail.com>: >>>> > > >>>> > > 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 >>>> > >>>> >>>> >> >> -- >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> (@rotty3000) >> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >> (@Liferay) >> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >> (@OSGiAlliance) >> > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
