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 09:17:42 GMT
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/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-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


Mime
View raw message