commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [BCEL6] StackMapTable / StackMapTableEntry gone
Date Wed, 08 Jun 2016 11:03:19 GMT
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/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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message