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

Rémi Forax wrote:
> I wonder if it's not better to create a special package "compat"
> with the abstract classes implementing the already existing interfaces.
> This will let users decide if they want the ability to use several
> version of visitors or not.

being able to use several versions of visitors is only a "by product" of 
the fact that we want to ensure backward compatibility (which is the 
main goal). Indeed, ensuring backward compatibility means that an old 
visitor written by users must still work with recent ClassReader and 
ClassWriter implementations. But a visitor + a reader and/or a writer is 
nothing more than a small "transformation" chain. Thus, supporting 
backward compatibility is equivalent to being able to support 
transformation chains with a mix of versions.

> Anyway, as Eric says, it will take times before having an implementation
> of that
> and we should not delay the release of ASM4.

do you think that users cannot wait one month?

> The package compat can be added in a following version, by ex. 4.1.

but it would eventually be removed, yielding yet another incompatible 
change. This contradicts its goal, which is to avoid incompatible 
changes in the future!

> On 08/19/2011 06:36 PM, Eric Bruneton wrote:
>> So far, I assumed that when a method signature is changed, i.e. when
>> we have several versions of a method in FooVisitor, users will
>> override *at most one* of these methods, the one corresponding to the
>> version declared in the FooVisitor constructor. It is easy to see
>> that, if this hypothesis is not respected, unexpected behavior can occur.
>>
>> And it is easy to arrive in such a situation without noticing it. It
>> suffice to have a subclass B of a class A itself extending FooVisitor:
>>
>> in version X we have:
>>
>> class A extends FooVisitor {
>> A(FooVisitor next) { super(V_X, next); }
>> void visitBar(int i) { ... behavior A ... }
>> ...
>> }
>>
>> class B extends A {
>> B(FooVisitor next) { super(next); }
>> void visitBar(int i) { ... behavior B ... }
>> }
>>
>> now suppose that A is provided by some library, and B by another (for
>> instance A is provided by ASM itself, e.g, it is a asm.commons
>> component, while B is provided by the user; or A is provided by
>> FindBugs, and B is provided by a 3rd party detector). At some time, A
>> is upgraded to version Y, but not B. Then we get:
>>
>> class A extends FooVisitor {
>> A(FooVisitor next) { super(V_Y, next); }
>> void visitBar(int i, int j) { ... behavior A ... }
>> ...
>> }
>>
>> and now B overrides both versions of visitBar, with different
>> behaviors in each version! Additionally, its version is wrongly

if we do not detect these situations, B will fail with ASM Y. If, on the 
other hand, we detect them, an exception will be thrown when trying to 
instantiate B. In both cases B is no longer usable.

In fact it is possible to do better. When can write version Y of A a bit 
differently so that B can still work with ASM Y, on classes that do not 
use the new features introduced in version Y:

class A extends FooVisitor {
     ...
     void visitBar(int i, int j) {
         if (version < V_Y) {
             super.visitBar(i, j);
         } else {
             ... behavior A ...
         }
     }
     ...
}

but in this case the fact that B will override both versions of visitBar 
(via inheritance) is no longer a problem, and so we must not throw an 
exception in these cases. Instead, we must hope that users will follow 
the above rule (that we can document) in their code.

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