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

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?

I personally would even vote for releasing the Eric's "abstract classes" proposal as ASM 4.0 RC2 and after a month or two just ship the 4.0. 
For those who can't wait another one month, just use ASM 4.0 RC2 or even build from SVN directly. 

What kind of problem solve two major incompatible ASM releases - initially planned 4.0 release AND another one release? It just increases user's pain.

What kind of issues one could expect from the "abstract classes" proposal released as 4.0? Are there some extra "extensive tests" which do not pass, except known ASM tests? If yes, just give them to the project to increase test coverage. Are there any observed performance degradations? Same here. Until then I do not see a problem to release the "abstract classes" proposal as 4.0 RC2 and then as 4.0 final and fix all the newly found issues in 4.1.

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

Yes, I also agree here. ASM is very well known and widely used library, and there is a large user base. Compatibility to old API's is one key to make users happy - actually this was one of the main Sun drivers behind  the chosen Java language/JDK evolution strategy :-). Oracle may have different opinion now, but people can still run ASM 3.3 on 1.4 level JVM's.

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

Thank you, this is exactly what we are looking for.

> 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.
[...]
> Eric


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. 

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.
-- 
Kind regards,
mit freundlichen Grüßen
Andrey Loskutov

@Home: http://andrei.gmxhome.de
Hinweis: diese Nachricht besteht nur aus den wiederverwertbaren Bits.

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