My specification attachments were over the mailer size limit - I have created https://issues.apache.org/jira/browse/BCEL-283 with the specs attached.
Mark > -----Original Message----- > From: Mark Roberts [mailto:mar...@cs.washington.edu] > Sent: Wednesday, November 09, 2016 8:26 AM > To: 'Commons Developers List' > Cc: mar...@cs.washington.edu > Subject: [BCEL6] StackMap vs. StackMapTable > > It turns out we made a mistake with these StackMap renaming changes. I > ran into a problem decoding some old .class files and went back to the Java > Specification Requests (JSRs) to try and understand the history of the > StackMap attribute. While I was not able to get the complete story, I have a > pretty good guess at what happened and it does explain the problem I have > seen. > > The official introduction of StackMaps appears to be JSR 202 from (approx.) > Sept. 2006 and it is part of JDK6 (see attached spec) . However, StackMaps > were originally proposed much earlier (approx.) March 2002 - see the > attached verifier spec. It appears there were some implementations of this > earlier specification - the ASM tool was one and there may be others. > > The key differences are: > Typechecker Spec: StackMap attribute with fixed format and no frame > type byte > JDK 6 Spec: StackMapTable attribute with variable format > including a frame type byte. > > The JVM and the javap tool support BOTH formats. BCEL recognizes both > attribute names, but treats them the same, as JDK6 version. > > I don't think the changes will be too difficult. I will create a new BCEL > issue > with a proposed fix within the next few days. > > Thank you, > Mark Roberts > > > -----Original Message----- > > From: Mark Roberts [mailto:mar...@cs.washington.edu] > > Sent: Wednesday, June 08, 2016 5:25 AM > > To: 'Commons Developers List' > > Subject: RE: [BCEL6] StackMapTable / StackMapTableEntry gone > > > > 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. > > > > 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/ea9d699ab042f6917 > > > > 40 > > > > 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.h > > > > tm > > > > l# > > > > 43817 > > > > >> > [4] > > > > >> > > > > > http://docs.oracle.com/javame/config/cldc/opt-pkgs/api/cldc/api/Ap > > > > pe > > > > nd > > > > 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
