Re: [Findbugs-core] toward ASM 4.0?

Hi Bill,

I can not speak for any 3rd party FB detector providers, but just  
*assuming* the "best" case:

1) ASM 4.0 will not change the package name
2) ASM will be refactored to use abstract classes instead of interfaces,  
as proposed by Eric

I do not see much trouble for the FB detector providers, as the only  
*really* affected FB interface is FBMethodVisitor, and I'm not sure if any  
client ever used this interface directly (and not via extending the  
AbstractFBMethodVisitor class).

The rest of the FB detectors code could be probably simply recompiled.
In the FB code itself we would need to change AbstractMethodVisitor which  
would then *extend* and not implement MethodVisitor, and refactor some  
code in and around the AbstractFBMethodVisitor/FBMethodVisitor, which  
should be also doable with not so much effort.

However if ASM 4.0 would change package name, it would clearly break the  
backward compatibility with old FB-ASM based detectors... The code change  
for FB and FB-ASM based detectors would be trivial however, as long as one  
have access to the FB detector source code. Also I expect that most of the  
people wrote BCEL based detectors, as almost all FB examples/detectors are  
doing that, so that the amount of incompatible detectors would be not so  
big.

So I would not give up with using ASM 4.0 for FB 2.0, *and* it would be  
good to make the ASM 4.0 transition at the FB 2.0 release and not later on.
I think people can expect some rework on FB version change from 1.3.9 to  
2.0, but it would be harder to sell the same thing for FB 2.1 version :-)

Regards,
Andrey


On Wed, 17 Aug 2011 00:01:38 +0200, Bill Pugh <[email protected]> wrote:

> OK. In short, replacing ASM 3.3 with ASM 4.0 isn't an option for  
> FindBugs. I'm not going to blow up all the existing ASM based detectors.
>
> The only question is whether to support both ASM 3.3 and ASM 4.0 for  
> writing detectors in FindBugs. Seems like a mess. Among other problems,  
> you'd run into all kinds of nightmares when you have IDE's suggest which  
> classes to import. And I'm not sure I could get it to fly at Google.
>
> Frankly, I think your plan to rename all the packages is a mistake. An  
> upgrade from 3.3 to 4.0RC1 required a 3 line change. The 4.0 release  
> plan makes the switch a huge deal, and frankly impossible for FindBugs.
>
> The decision is unfortunate. I would be nice to be able to correctly  
> handle invoke dynamic. It is a shame there isn't a released version of  
> ASM that is backwards compatible with 3.3 and correctly handles invoke  
> dynamic.
>
> Bill
>
>
>
> On Aug 16, 2011, at 5:45 PM, Eric Bruneton wrote:
>
>> 16/08/2011 09:33, Bill Pugh wrote:
>>> I'm looking at the feasibility of moving FindBugs to ASM 4.0.
>>>
>>> Moving to 4.0_RC1 was fairly trivial. I just needed to provide an
>>> implementation of visitInvokeDynamic in a MethodVisitor.
>>>
>>> However, the changes between 4.0_RC1 and 4.0 seem to be a showstopper.
>>>
>>>> we mostly
>>>> renamed the package from org.objectweb.asm to org.ow2.asm, and we
>>>> renamed two classes (MethodHandle to Handle, and MethodType to Type)
>>
>> Eugene proposed to rename the package so that users will not need to  
>> rename it themselves to avoid binary incompatibilities (it seems some  
>> products include 4 or 5 repackaged versions of ASM). From what you say,  
>> it seems that whatever the option we choose, some users will not be  
>> satisfied :-(
>>
>>> This is going to require updating all references to asm classes within
>>> FindBugs, and more importantly, will /completely break /any third-party
>>> bug detectors written using ASM.
>>>
>>> I don't know how many of those there are. But breaking them all seems
>>> rather rude, and a good way to discourage people from writing ASM based
>>> detectors in the feature.
>>>
>>> At Google, and probably elsewhere, they have a very strict policy of
>>> using only one version of a third-party library. So it would be hard to
>>> update FindBugs inside Google to use ASM 4.0 unless I migrated all uses
>>> of ASM to 4.0. Which would be a lot of work.
>>>
>>> If you really want to completely rename the packages, I'd suggest  
>>> making
>>> the new release be NewASM 1.0. That would allow for NewASM 1.0 and ASM
>>> 3.3 to co-exist.
>>>
>>> Bill
>


-- 
Kind regards,
Mit freundlichen Grüßen
Andrey Loskutov

@Home: http://andrei.gmxhome.de/

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