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

On 08/24/2011 11:33 AM, Andrey Loskutov wrote:
> Hi all,
>
> although I'm not the core ASM developer, at least as client of ASM API's (Bytecode Outline and FindBugs) I feel that I also can add few comments to the discussion.
>
> -------- Original-Nachricht --------
>> Datum: Wed, 24 Aug 2011 08:44:25 +0200 (CEST)
>> Von: [email protected]
>> An: Brian Goetz<[email protected]>
>> CC: "Rémi Forax"<[email protected]>, Bill Pugh<[email protected]>, [email protected], [email protected], jeffrey zeeb<[email protected]>, [email protected]
>> Betreff: Re: [asm] 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.
> This is exact the problem: why force users to fight with *two* incompatible changes if one could do it only once?

Because we need time to be sure that this will not severely impact our 
users.

[...]

>
> BTW, about the Java 8 features: IMHO ASM 4.0 can still be compiled to the 1.4 level and so run on any VM from 1.4 to 1.8. Changing ASM code in the way that it tightly depends on the *latest greatest* JVM will make ASM 5.+ unusable for almost all corporate users which are usually very conservative in the VM choice.

Technically, ASM requires 1.5 level and the generated bytecode is downgraded
to be 1.3 compatible (generics signature are removed, StringBuilder 
rewritten to StringBuffer etc.)

So even if we choose to use new feature at compile time, we will 
downgrade them
(of course if we are able to :)

>
> So even if Java 8 will solve all potential ASM compatibility problems described by Eric (the proof is pending :-)), this would lock ASM 5.0 to the Java 8 and lock users for *years* from using ASM 5.*.
>
> In my company we are still using 1.6.0_16 because all consequent bugfix releases were too buggy/unstable to switch to. 1.7.0 is also not a choice due the well known issues with lucene etc... So even if we entirely control our platform (we are in the happy but seldom position here), we can not switch to 1.7 in the near future.
>
> Another example - one of ASM users is Eclipse PDE, and it is also (in core platform) still 1.4.0 compatible. They will NEVER allow 1.8 dependency just because ASM 5.0 needs it, and I guess it will take 10+ years until Eclipse will be 1.8 dependent.
>
> So while proposing the way how ASM API could be made compatible, one should consider that not everyone can just pick the latest available JDK release.

I really think we can come with a way to provide 3 jars
(if we don't count the small jars that only contains one package).
One which is used when you compile and which is 1.8 compatible
(it at least declares itself as a module), this one provide source 
compatibility
and old method/class are deprecated.
One which is binary backward compatible and use bridges as Eric describes
to redirect old code to new one.
You can also compile against this one if you don't want to use 1.5/1.8 
features.
One which is only compatible with the current state of ASM i.e.
which works if you only use methods that are not deprecated.

We should also provide two javadocs one with only the current API
and one with all the backward compatibility stuff.

cheers,
Rémi

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