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

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