commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Roberts" <mar...@cs.washington.edu>
Subject [BCEL6] StackMap vs. StackMapTable
Date Wed, 09 Nov 2016 17:09:25 GMT
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:markro@cs.washington.edu]
> Sent: Wednesday, November 09, 2016 8:26 AM
> To: 'Commons Developers List'
> Cc: markro@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:markro@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:james@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 <sebbaz@gmail.com> wrote:
> > >
> > > > On 8 June 2016 at 10:01, Andrey Loskutov <loskutov@gmx.de> wrote:
> > > > > On Wednesday 08 June 2016 08:37 Benedikt Ritter wrote:
> > > > >> Hallo Andrey,
> > > > >>
> > > > >> Andrey Loskutov <loskutov@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-unsubscribe@commons.apache.org
> > > > >> > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >> >
> > > > >> >
> > > > >
> > > > > --
> > > > > Kind regards,
> > > > > google.com/+AndreyLoskutov
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > - To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > --
> > > > - To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: dev-help@commons.apache.org
> > > >
> > > >



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message