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
