asm7 preparation

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

asm7 preparation

Romain Manni-Bucau
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 BlogGithub | LinkedIn | Book
Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

Mark Struberg
We should analyse if ASM7 is a drop-in replacement and can be used in a backward compatible way.
If so, then we could keep the shaded o.a.g.asm6 package and just document it.
If ASM7 removed some old methods, then we really should also shade to a private asm7 package.

LieGrue,
strub


> Am 30.09.2018 um 19:44 schrieb Romain Manni-Bucau <[hidden email]>:
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

Romain Manni-Bucau


Le lun. 1 oct. 2018 à 12:39, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

Mark Struberg
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 <[hidden email]>:
>
>
>
> Le lun. 1 oct. 2018 à 12:39, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> >
> > 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
>

Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

Romain Manni-Bucau



Le lun. 1 oct. 2018 à 14:26, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
>
>
> Le lun. 1 oct. 2018 à 12:39, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> >
> > 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
>

Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

Raymond Auge
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 <[hidden email]> wrote:



Le lun. 1 oct. 2018 à 14:26, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
>
>
> Le lun. 1 oct. 2018 à 12:39, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> >
> > 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é (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

Romain Manni-Bucau

Le lun. 1 oct. 2018 à 15:37, Raymond Auge <[hidden email]> 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 <[hidden email]> wrote:



Le lun. 1 oct. 2018 à 14:26, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
>
>
> Le lun. 1 oct. 2018 à 12:39, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> >
> > 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é (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

Raymond Auge
FYI, here's a diff of the API


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 <[hidden email]> wrote:

Le lun. 1 oct. 2018 à 15:37, Raymond Auge <[hidden email]> 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 <[hidden email]> wrote:



Le lun. 1 oct. 2018 à 14:26, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
>
>
> Le lun. 1 oct. 2018 à 12:39, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> >
> > 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é (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)


--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

Romain Manni-Bucau
:) as usual with asm, looks ok but breaks several apps ;). But main point is: do we want to export as asm6 the real asm7 and fake the runtime it will work? If we want a smooth upgrade we can update asm6 module to have some of changes but keep asm7 module to ensure we cover it IMHO.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le lun. 1 oct. 2018 à 16:03, Raymond Auge <[hidden email]> a écrit :
FYI, here's a diff of the API


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 <[hidden email]> wrote:

Le lun. 1 oct. 2018 à 15:37, Raymond Auge <[hidden email]> 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 <[hidden email]> wrote:



Le lun. 1 oct. 2018 à 14:26, Mark Struberg <[hidden email]> 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 <[hidden email]>:
>
>
>
> Le lun. 1 oct. 2018 à 12:39, Mark Struberg <[hidden email]> 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 <[hidden email]>:
> >
> > 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é (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)


--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

David Blevins-2
In reply to this post by Romain Manni-Bucau
> On Sep 30, 2018, at 10:44 AM, Romain Manni-Bucau <[hidden email]> wrote:
>
> 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.

Like you I like 4, but 3 is probably the smartest option. I didn't care for option 3 when Mark suggested it years ago, but in hindsight it has worked out very well.

Truthfully, if the ASM versioned their own packages like that, we wouldn't need to shade it all and neither would anyone.


-David

Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

David Blevins-2
In reply to this post by Romain Manni-Bucau
> On Oct 1, 2018, at 7:12 AM, Romain Manni-Bucau <[hidden email]> wrote:
>
> :) as usual with asm, looks ok but breaks several apps ;). But main point is: do we want to export as asm6 the real asm7 and fake the runtime it will work? If we want a smooth upgrade we can update asm6 module to have some of changes but keep asm7 module to ensure we cover it IMHO.

We should definitely not introduce ASM 7 code into our asm6 module.

Another topic is we've been on ASM 6 for 2 years.  Should we change the XBean major version to 5 when we switch to ASM 7?

That would give us the option to keep pushing out XBean 4.x releases with further ASM 6 updates for those who can't/won't upgrade yet or also have stable branches to maintain.

If if we don't change the major version and any critical bugs or security vulnerabilities hit XBean 4.10, we'd have to do a 4.10.1.  If that happened a few times we'd find ourselves with 4.10.2, 4.10.3 and effectively maintaining a de facto branch, just after the fact and in a very awkward way.


-David

Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

Romain Manni-Bucau




Le mar. 2 oct. 2018 à 00:34, David Blevins <[hidden email]> a écrit :
> On Oct 1, 2018, at 7:12 AM, Romain Manni-Bucau <[hidden email]> wrote:
>
> :) as usual with asm, looks ok but breaks several apps ;). But main point is: do we want to export as asm6 the real asm7 and fake the runtime it will work? If we want a smooth upgrade we can update asm6 module to have some of changes but keep asm7 module to ensure we cover it IMHO.

We should definitely not introduce ASM 7 code into our asm6 module.

Another topic is we've been on ASM 6 for 2 years.  Should we change the XBean major version to 5 when we switch to ASM 7?

Since some years I really think we should explode xbean to be able to have this real versioning otherwise we are always between "this part needs a new major but not this one for consistency".
 

That would give us the option to keep pushing out XBean 4.x releases with further ASM 6 updates for those who can't/won't upgrade yet or also have stable branches to maintain.

Strictly speaking we can have asm[3-7] in the same source tree so not sure it helps to move in one direction or the other.
 

If if we don't change the major version and any critical bugs or security vulnerabilities hit XBean 4.10, we'd have to do a 4.10.1.  If that happened a few times we'd find ourselves with 4.10.2, 4.10.3 and effectively maintaining a de facto branch, just after the fact and in a very awkward way.

I actually like that for multiple reasons:

1. upgrading is a very doable work for all projects which would require such an upgrade so not a blocker
2. we can always lazily create a maintenance branch from a tag (vs eagerly which is generally useless) and when done it does not get more love than the CVE fix if it exists

At the end it is the less costly solution IMHO.
 


-David

Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

Romain Manni-Bucau
Trying to go back to action: any objection to release master as it (ie with asm7 module and a dropped asm6 module)? Sounds like the best compromise we can get - and the same as commons.

Side note: if we need we can create a maintenance branch for asm6 but from experience we always moved forward - cause java support way ;) - and never needed to go back so sounds good enough to move forward to keep trunk as it.

If no objection I will try to launch it hopefully tomorrow or later this week.

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 2 oct. 2018 à 09:21, Romain Manni-Bucau <[hidden email]> a écrit :




Le mar. 2 oct. 2018 à 00:34, David Blevins <[hidden email]> a écrit :
> On Oct 1, 2018, at 7:12 AM, Romain Manni-Bucau <[hidden email]> wrote:
>
> :) as usual with asm, looks ok but breaks several apps ;). But main point is: do we want to export as asm6 the real asm7 and fake the runtime it will work? If we want a smooth upgrade we can update asm6 module to have some of changes but keep asm7 module to ensure we cover it IMHO.

We should definitely not introduce ASM 7 code into our asm6 module.

Another topic is we've been on ASM 6 for 2 years.  Should we change the XBean major version to 5 when we switch to ASM 7?

Since some years I really think we should explode xbean to be able to have this real versioning otherwise we are always between "this part needs a new major but not this one for consistency".
 

That would give us the option to keep pushing out XBean 4.x releases with further ASM 6 updates for those who can't/won't upgrade yet or also have stable branches to maintain.

Strictly speaking we can have asm[3-7] in the same source tree so not sure it helps to move in one direction or the other.
 

If if we don't change the major version and any critical bugs or security vulnerabilities hit XBean 4.10, we'd have to do a 4.10.1.  If that happened a few times we'd find ourselves with 4.10.2, 4.10.3 and effectively maintaining a de facto branch, just after the fact and in a very awkward way.

I actually like that for multiple reasons:

1. upgrading is a very doable work for all projects which would require such an upgrade so not a blocker
2. we can always lazily create a maintenance branch from a tag (vs eagerly which is generally useless) and when done it does not get more love than the CVE fix if it exists

At the end it is the less costly solution IMHO.
 


-David

Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

Mark Struberg
In reply to this post by David Blevins-2
Not 100% sure we should go xbean-5.x. Otoh I'm totally fine either ways.
We might end up pushing the major version every half a year with the new Java cadence :(

Another thought:
It might happen that we have both shaded asm6 and 7 for a short period in time in TomEE.
But as soon as xbean-asm7 is done I'll run OpenJPA and OpenWebBeans releases with the new xbean-asm7.
So this period should really only be very short. And possibly we even manage to get it down to nada.

LieGrue,
strub

> Am 02.10.2018 um 00:34 schrieb David Blevins <[hidden email]>:
>
>> On Oct 1, 2018, at 7:12 AM, Romain Manni-Bucau <[hidden email]> wrote:
>>
>> :) as usual with asm, looks ok but breaks several apps ;). But main point is: do we want to export as asm6 the real asm7 and fake the runtime it will work? If we want a smooth upgrade we can update asm6 module to have some of changes but keep asm7 module to ensure we cover it IMHO.
>
> We should definitely not introduce ASM 7 code into our asm6 module.
>
> Another topic is we've been on ASM 6 for 2 years.  Should we change the XBean major version to 5 when we switch to ASM 7?
>
> That would give us the option to keep pushing out XBean 4.x releases with further ASM 6 updates for those who can't/won't upgrade yet or also have stable branches to maintain.
>
> If if we don't change the major version and any critical bugs or security vulnerabilities hit XBean 4.10, we'd have to do a 4.10.1.  If that happened a few times we'd find ourselves with 4.10.2, 4.10.3 and effectively maintaining a de facto branch, just after the fact and in a very awkward way.
>
>
> -David
>

Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

Romain Manni-Bucau
Think we are all about xbean 4 ;).

Agree it shouldn't be an issue and more than a snapshot state to have 2 asm versions in tomee now.

Side note: my personal feeling is that we'll explode xbean and never do a 5.x to have an asm (asm shade + util + proxy base tool?) subproject and telnet, blueprint etc subprojects. Would simplify the maintenance and lifecycle...but this is another thread of discussion for later ;).

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 2 oct. 2018 à 17:48, Mark Struberg <[hidden email]> a écrit :
Not 100% sure we should go xbean-5.x. Otoh I'm totally fine either ways.
We might end up pushing the major version every half a year with the new Java cadence :(

Another thought:
It might happen that we have both shaded asm6 and 7 for a short period in time in TomEE.
But as soon as xbean-asm7 is done I'll run OpenJPA and OpenWebBeans releases with the new xbean-asm7.
So this period should really only be very short. And possibly we even manage to get it down to nada.

LieGrue,
strub

> Am 02.10.2018 um 00:34 schrieb David Blevins <[hidden email]>:
>
>> On Oct 1, 2018, at 7:12 AM, Romain Manni-Bucau <[hidden email]> wrote:
>>
>> :) as usual with asm, looks ok but breaks several apps ;). But main point is: do we want to export as asm6 the real asm7 and fake the runtime it will work? If we want a smooth upgrade we can update asm6 module to have some of changes but keep asm7 module to ensure we cover it IMHO.
>
> We should definitely not introduce ASM 7 code into our asm6 module.
>
> Another topic is we've been on ASM 6 for 2 years.  Should we change the XBean major version to 5 when we switch to ASM 7?
>
> That would give us the option to keep pushing out XBean 4.x releases with further ASM 6 updates for those who can't/won't upgrade yet or also have stable branches to maintain.
>
> If if we don't change the major version and any critical bugs or security vulnerabilities hit XBean 4.10, we'd have to do a 4.10.1.  If that happened a few times we'd find ourselves with 4.10.2, 4.10.3 and effectively maintaining a de facto branch, just after the fact and in a very awkward way.
>
>
> -David
>

Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

David Blevins-2
In reply to this post by Mark Struberg
> On Oct 2, 2018, at 8:48 AM, Mark Struberg <[hidden email]> wrote:
>
> Otoh I'm totally fine either ways.

For clarity, though I made the suggestion, I'm fine either way as well.

There might be a few 4.10.x in our future, but it wouldn't be terrible.

I definitely see how a 5x change has the opportunity to make everyone suddenly ambitious which usually pushes things out.

I'm good with whatever.


-David


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: asm7 preparation

Romain Manni-Bucau
Ok, then i'll try to launch 4.11 today, thanks guys and noted that we must discuss xbean future soon - we can plan it for next year maybe?

Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book


Le mar. 2 oct. 2018 à 23:11, David Blevins <[hidden email]> a écrit :
> On Oct 2, 2018, at 8:48 AM, Mark Struberg <[hidden email]> wrote:
>
> Otoh I'm totally fine either ways.

For clarity, though I made the suggestion, I'm fine either way as well.

There might be a few 4.10.x in our future, but it wouldn't be terrible.

I definitely see how a 5x change has the opportunity to make everyone suddenly ambitious which usually pushes things out.

I'm good with whatever.


-David