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

Hi all,

as someone that uses ASM for bytecode weaving, I strongly support
Rémi's objection against moving forward to fast into a direction that
might harm usage of ASM as tool for bytecode weaving.

In my opinion, it is best to address backward compatibility in adapters
outside of the core libraries. In fact, I did not even use the default
ASM adapters in my weavers and find an approach to enforcement support
of these less appealing.

Please do not take action in this direction without giving users a
chance to evaluate and discuss the consequences.

Best regards

Tronje


Rémi Forax wrote:
> 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
> 

-- 
     Tronje Krop <[email protected]>

   Encrypted eMail welcome! GPG/PGP-Key: 0x9AD43A05
  68E5 A3D3 75A0 B096 AC75  62D5 8EEE 3D18 9AD4 3A05

 No responsibility is taken for the correctness of the
previous information. Please delete if you receive this
                  mail unintentional.

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