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

On 08/19/2011 08:32 PM, Eric Bruneton wrote:
> 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.
> if the VM will be ready, we will switch to method handle.

I agree. But I see this as trade-of between full compatibility and speed.
As a writer of a findbugs plugin, I want this compatibility, as a writer 
of the runtime
of PHP.reboot which generate bytecode at runtime, I don't want this 
compatibility,
I want full speeeeeed :)

>
>> 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?

Why waiting ? I see no reason.

>
>> 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!

The purpose of such package is to guarantee the backward compatibility,
why do you want to remove it ?
I don't understand.

Rémi

>
>> 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