On 8 June 2016 at 13:24, Mark Roberts <mar...@cs.washington.edu> wrote: > There were duplicate versions of these methods with slightly different names. > We picked the set that seemed to have a better implementation and deleted > the other two. This was done as part of the last two pushes to 6.0 (approx. > Feb 2015 and Aug 2015). A lot of these changes were porting numerous bug > fixes and enhancements we (the PLSE group at University of Washington) had > done to our version of BCEL to provide some basic support for StackMaps so > our tools (Daikon, in particular) could fully support Java 7 and Java 8. See > BCEL issues 194 through 213 for some general back ground. > > On a related note, as a huge user of the current state of BCEL, we have no > interest in any form of a 5.x release; nor in any release that would require > us to reedit all of our previous changes in the name of backward > compatibility. We ARE interested in improved support for Java 8 and Java 9.
What we are currently working on is making trunk backwards compatible with 5.2 without dropping the fixes added for Java 8 and 9. This will require downstream users who have used the unreleased trunk code (such as yourselves) to change package and Maven coords but AFAICT there should be no other change needed. This should give the best outcome for all concerned in the short term at least. > Thank you, > Mark Roberts > >> -----Original Message----- >> From: James Carman [mailto:ja...@carmanconsulting.com] >> Sent: Wednesday, June 08, 2016 4:03 AM >> To: Commons Developers List >> Subject: Re: [BCEL6] StackMapTable / StackMapTableEntry gone >> >> 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/ea9d699ab042f691740 >> > ef59aedd365ba27fb27f8 >> > . >> > > >> > > 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/Append >> > ix1-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 >> > >> > > > > --------------------------------------------------------------------- > 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
