Re: Re: Re: [Findbugs-core] toward ASM 4.0?

Hi Eric,
We have several kind of users, by example I use ASM as a bytecode generator
in several compiler backends and as a bytecode transformer in several
bytecode weavers.

I don't care about the size of ASM libs and even of the speed of ASM
in a compiler, usually the phase before the generation takes more time.
But in a weaver, the libs have to be as small as possible because it will
be included in several projects and I don't want to create a dependency
of several megs and as fast as possible because usually you have 1000
to 10000 classes to rewrite so each instructions is important in the 
adapter chain
because the whole chain is hot.

What you propose will impact the size of the jars and the execution time,
so I want to explore the different options and not to rush and release
something that will be not used.

I understand your will to release something that will be break the user
codebase once instead of twice (once for ASM4 and once for ASM5)
but if we release ASM4 as is, there are incompatibilities with ASM3
but not more than between ASM2 and ASM3 so I think ASM users are
already used to this kind of incompatibilities and
this will let us time to explore the design issues and test ASM5.

Currently ASM4 uses generics but is 1.3 (1.4 for the package xml) compatible
because you can compile against one jar and run against another.
I hope we can provide several kind of jars to avoid to users that use 
ASM as a weaver
to pay the price of the backward compatibility if they don't want it.

Also don't forget that a lot of company will never accept to have part
of their stack that use different versions of ASM even
if we ensure full backward compatibility.

So yes, users will be bothered because they will have updated ASM twice
when JDK8 will be out but in the same time they will still be able to use
ASM in bytecode weavers.

That's why, I really think we should release ASM4 as is and
focus to create a new ASM5 that let our users choose if they want
to pay the backward compatibility price or not.

Rémi

On 08/24/2011 08:44 AM, [email protected] wrote:
> Rémi Forax wrote:
>> A release is a release (as you can guess by it's name),
>> so bug will be fixed, etc.
> we no longer maintain ASM 1.x or 2.x as far as I know...
>
>> But please, we have time to implement this change, I don't understand
>> why you want
>> to release ASM 5 in a hurry without extensively test and gather users
>> data
>> for something which is a major change in the design of ASM.
> ASM 4.0 RC1 introduces backward incompatible changes. ASM 5.0 will also introduce backward incompatible changes, but these will be the last ones. Releasing ASM 5.0 directly would save trouble to users, who would need to update their code only once, instead of twice. But if users are OK for two incompatible changes, I can wait two years for ASM 5.0.
>
> Brian Goetz wrote:
>> Renaming packages is a radical step that will make a lot of people
> renaming the package or not is not important for me. What is essential is the support for backward compatibility.
>
>> unhappy (by breaking binary compatibility for everyone), seemingly for
>> the benefit of a few "advanced" users.  (And, we may be forced to
>> rename
>> packages if/when we bundle ASM with the JDK, and making users suffer
>> through two package renames in less than two years would be awful.)
> adding or changing a single method suffices to break binary compatibility and to make users unhappy, as ASM 4.0 will do. This is what I'm trying to avoid as much as possible by proposing to release an ASM version that fixes this issue right now, and not in two years.
>
> Brian Goetz wrote:
>> Again I urge you to look at how the Java 8 features will help:
>> extension
>> methods (for compatible evolution of interfaces) and modules (for
>> explicit versioning management.)  These are exactly the problems you
>> are
>> struggling with.  You've suffered this long with these problems, might
>> as well wait for the real solutions.
> this is your idea, not mine, and I don't know much about these two features. I think the one that must prove that they can be used to ensure backward compatibility is you, not me.
> So can you please give a concrete code example, showing how extension methods can be used in the following four use cases? And also how this would work internally, and what the performance would be? I need technical arguments to be convinced.
>
> In ASM version X, FooVisitor contains a method visitBar(int)
>
> A user writes a class A that implements this interface.
>
> In ASM version Y, two methods are added in FooVisitor: visitBar(int,int), intended to replace visitBar(int) (visitBar(i,0) is equivalent to visitBar(i)), and a completely new method visitBaz(int).
>
> case 1: class A, unchanged, must be instantiable with ASM Y (although it does not implement the two new methods), and must fail when visitBaz is called. If visitBar(i,0) is called on A, this call must be redirected to visitBar(i). If visitBar(i,j) is called on A (j!=0), the call must fail.
>
> case 2: the user updates class A to use the new ASM Y API. He provides a visitBaz implementation, removes the visitBar(int) method, and replaces it with an improved version conforming to the visitBar(int,int) signature. *He must not be forced to implement the old method visitBar(int)*. If visitBar(i) is called on this new version of A, this call must be redirected to visitBar(i,0). If visitBar(i,j) is called, it must now run the code written by the user (recall that on the original version of A, the same call must lead to a redirection or a failure). If visitBaz(int) is called on A, it must now run the code provided by the user.
>
> -----------
>
> ASM version X also provides a class FooAdapter implementing FooVisitor with methods that delegate their work to another FooVisitor instance.
>
> A user writes a class B that extends FooAdapter and overrides visitBar(int), and a class C that extends FooAdapter but does not override visitBar(int).
>
> In ASM version Y, FooAdapter implements the two new methods of FooVisitor in the same way as the original ones.
>
> case 3: class B and C, unchanged, must be instantiable with ASM Y, and must fail when visitBaz(int) is called. If visitBar(i,0) is called on B, it must be redirected to the visitBar(int) method in B. If visitBar(i,0) is called on C, it must be delegated to the next FooVisitor by FooAdapter. If visitBar(i,j) (j!=0) is called on B or C, the call must fail.
>
> case 4: the user updates class B in a similar way as class A (remove visitBar(int), replace it with visitBar(int,int), provide a visitBaz implementation). He does not update C, except to specify that it is now supporting ASM Y (you can choose the way to do that). If visitBar(i) is called on B, it must now be redirected to visitBar(i,0). If visitBar(i) is called on C, it must be delegated to the next visitor by FooAdapter, via visitBar(i) or visitBar(i,0). If visitBar(i,j) or visitBaz are called on B, they must now run the user code. If visitBar(i,j) or visitBaz are called on C, they must now be delegated to the next visitor by FooAdapter.
>
> Eric

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws