I think I've found a way to fix the compile problems without introducing back StackMapTable / StackMapTableEntry classes to BCEL6, see https://github.com/findbugsproject/findbugs/commit/2e1807e82c18ce646e0298b8d0597e5eeb49c0af
FindBugs is now compilable on BCEL6 latest greatest head, but our tests are failing, see https://issues.apache.org/jira/browse/BCEL-273. I'm working on fixing them and will be back if I will find something to fix on BCEL side. Thanks all for the feedback & support! On Wednesday 08 June 2016 10:46 sebb wrote: > On 8 June 2016 at 10:34, Andrey Loskutov <losku...@gmx.de> wrote: > > On Wednesday 08 June 2016 10:17 sebb wrote: > >> 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. > > > > One proposal (following A) is https://github.com/apache/commons-bcel/pull/5 > > Sorry, but that's not suitable as-is because it mixes various different > changes. > And AFAICT it also makes some unnecessary changes. > > > I'm not sure regarding the deprecation, since we will have to parse 1.5 > > class files forever. > > The intention would be to ensure that new code uses the better API. > > > B will unfortunately break FB clients > > That's a pity. > > > because we had a really bad idea to use those "not released" > > StackMapTable/StackMapTableEntry types to our visitor interface, and this > > since "ever" (2.0.3 released in 2010). > > That's a separate issue, but Findbugs really needs to introduce its > own API for add-ons, and deprecate the existing interfaces. > It should not expose any APIs except its own so it is in control. > This needs to be done as soon as practicable so plugin devs can start > updating their code. > > > -- > > Kind regards, > > google.com/+AndreyLoskutov -- Kind regards, google.com/+AndreyLoskutov --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
