commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [BCEL6] StackMapTable / StackMapTableEntry gone
Date Wed, 08 Jun 2016 14:56:45 GMT
On 8 June 2016 at 13:24, Mark Roberts <markro@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: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/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-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
>

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


Mime
View raw message