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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
