Let's be clear here. We are proposing changing the code because someone used a SNAPSHOT version and released their code which uses it? That code was never released and I don't know that it's right to bind us to a work-in-progress. It's bad enough we have to be saddled forever with the burden of backward compatibility on code we release.
On the other hand, we've done a very poor job of releasing the library, so folks did what they had to do to get the new features/fixes. So, there definitely are two sides to this situation. On Wed, Jun 8, 2016 at 5:17 AM sebb <seb...@gmail.com> wrote: > On 8 June 2016 at 10:01, Andrey Loskutov <losku...@gmx.de> wrote: > > On Wednesday 08 June 2016 08:37 Benedikt Ritter wrote: > >> Hallo Andrey, > >> > >> Andrey Loskutov <losku...@gmx.de> schrieb am Mi., 8. Juni 2016 um > 09:36 Uhr: > >> > >> > Hi, > >> > > >> > I'm following the package rename and trying to fix compile issues with > >> > BCEL6 in FindBugs. > >> > > >> > Before 6.0 we had both StackMap and StackMapTable classes (with > >> > StackMapEntry / StackMapTableEntry elements). > >> > This was added via https://issues.apache.org/jira/browse/BCEL-92 to > >> > support Java 6. > >> > > >> > Now in trunk I see that StackMapTable and StackMapTableEntry were > >> > removed, via https://issues.apache.org/jira/browse/BCEL-248. > >> > > >> > This causes few compile issues in FindBugs, and I see also no reason > why > >> > it should be removed either. > >> > > >> > Unfortunately, Java 1.6 documentation [3] doesn't mentioned neither > >> > StackMapTable nor StackMap attributes (or I'm unable to find it). > >> > The official JVM documentation for Java SE 1.7 /1.8 mentions only > >> > StackMapTable attribute, see [1,2]. > >> > StackMap attribute seems to be mentioned in Java ME specs, see [3]. > >> > In ASM code I see StackMap seem to be used for classfile versions < > 50 (< > >> > Java 6) and StackMapTable otherwise. > >> > > >> > If I understand it right, *both* attributes can appear in class > files, and > >> > StackMapTable is the one we have to deal with most the time on a > standard > >> > Java >= 6. > >> > > >> > So please can we restore the state where we have StackMapTable / > >> > StackMapTableEntry classes , to avoid further confusion and API > breakage in > >> > BCEL6? > >> > > >> > >> I'm confused. As far as I can tell those classes don't show up in the > >> latest Clirr report [1]. I don't understand why they are missing. Any > idea? > > > > A-ha, that surprises me too now, but after some software archaeology it > is clear why: the latest official 5.2 release is from June 3 2006, which of > course never "officially" supported Java 6 released in 2006-12-23. > > > > The Java 6 StackMapTable support was added to BCEL 2008 (via BCEL-92), > but there were not a single BCEL release since 2006, so the change was > never officially published! > > > > FindBugs used a BCEL 5.2 trunk *snapshot*, which included those BCEL-92 > changes. I see for example commit from 2010 which added reference to the > StackMapTable type: > https://github.com/findbugsproject/findbugs/commit/ea9d699ab042f691740ef59aedd365ba27fb27f8 > . > > > > So that's really not nice. I don't know what the best way to fix it. > > OK, so what options are there? > > A) add the classes back in, but deprecate the class(es) and defer to > the new implementation if possible > B) Update Findbugs to use the new design > > Anything else? > > == > > If the choice is between A and B, then B seems better since it looks > like FindBugs will need some other updates anyway. > However if changing Findbugs would break the plugin API then I think A > would be a better choice. > > I think we need to be pragmatic about the design of any code added to > the replacement for 5.2. > Yes, we should strive for good design, but if that breaks downstream > usage in a way that cannot be fixed, then we should do what works best > overall. > > >> Benedikt > >> > >> [1] http://commons.apache.org/proper/commons-bcel/clirr-report.html > >> > >> > >> > > >> > [1] > >> > > https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.7.4 > >> > [2] > >> > > https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.4 > >> > [3] > >> > > https://docs.oracle.com/javase/specs/jvms/se6/html/ClassFile.doc.html#43817 > >> > [4] > >> > > http://docs.oracle.com/javame/config/cldc/opt-pkgs/api/cldc/api/Appendix1-verifier.pdf > >> > > >> > -- > >> > Kind regards, > >> > google.com/+AndreyLoskutov > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> > For additional commands, e-mail: dev-h...@commons.apache.org > >> > > >> > > > > > -- > > Kind regards, > > google.com/+AndreyLoskutov > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
