Hello Andrey, the current plan is:
- trunk had breaking changes which were mostly reverted. We did this to push out one last release of the 5.2 line with all the fixes that had gone into BCEL. - We're going to do one last 5.x release soon. For this we're going to branch trunk and do a rename of the packages so that that release will be binary compatible with the 5.x line. AFAICT that release won't cover all the feature needed for Java 8 and 9 - After the 5.x release, we plan to start implementing the missing stuff to make it work with Java 8. - We haven't thought about Java 9 support but we welcome any input. Thank you! Benedikt Andrey Loskutov <losku...@gmx.de> schrieb am Mo., 6. Juni 2016 um 20:31 Uhr: > Hi all, > > this is a follow up on > https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-June/004282.html > . > > I'm cross-posting this to dev@commons.apache.org because the discussion > on FindBugs mailing list is related to the BCEL 6 API future, and because I > would like to know the opinions from the BCEL community on the upcoming > BCEL 6 release compatibility story. > > Please see my answers inline. > > On Monday 06 June 2016 17:30 sebb wrote: > > On 6 June 2016 at 16:23, Andrey Loskutov <losku...@gmx.de> wrote: > > > Hi all, > > > > > > here is the current state of FindBugs adoption to Java 9. > > > > > > 1) FindBugs standalone/Eclipse plugin run fine now on/with Java 9, the > latest code is on java9 branch (not on master yet!), see [0, 1]. If there > is interest, I can provide binary snapshots. > > > > > > 2) I have difficulties to use BCEL6 trunk, see [2]. Looks like even > after fixing all compile errors due the various API breakages in BCEL 6 > (see [3]), the current BCEL 6 head can't be used directly as a replacement > for our old BCEL5.2 fork, see [4]. If anyone from FB and/or BCEL gurus > could check this, this would be really helpful. Either our BCEL 5.2 patches > were not fully propagated upstream to BCEL or BCEL 6 trunk has few > regressions, or I missed something during update? I have no idea, because > of the next point below. The experimental BCEL 6 port is on an extra branch > on top of Java 9 related changes, see commits prefixed with BCEL6 on > java9_bcel6 branch at [5]. > > > > > > 3) I would be very happy if someone (Bill?) would explain how the > *current* BCEL5.2 fork used by FindBugs was built? It was added in commit > [6] but I miss instructions how it differs from the original BCEL code and > so unable to re-build it. > > > > > > 4) Assuming BCEL6 bugs/FB errors would be fixed (see [4]), transition > to the current BCEL6 head would break each and every FindBugs client, > because BCEL6 at current state uses different namespace and also added some > other API breaking changes. If we chose this path, none of the 3rd party > detectors will work anymore and therefore we must bump FindBugs version to > 4.0. > > > > This is useful to know. > > So do the 3rd party detectors depend on the BCEL namespace? > > Yes > > > Or is it because of the BCEL API changes? > > Also yes. > > > If so, which ones? > > The biggest one is the package namespace change, because this affect each > existing BCEL class/interface. > See commit > https://github.com/findbugsproject/findbugs/commit/917b692d9a12e048921cd1216102b851866ac3e4 > which affects ~400 files in FindBugs. > > Much smaller (but still breaking API) changes were class name changes > Constants -> Const, StackMapTable[Entry] -> StackMap[Entry] and the move of > constants defined in Constants from the interface to the class, thus > breaking everyone who implemented the interface and now miss the constants. > The rename of StackMapTable/Entry broke also additionally every detector > implemented on top of PreorderVisitor. StackMapTableEntry not only changed > its name, but also changed signature: getByteCodeOffsetDelta -> > getByteCodeOffset which gives you an additional piece of happiness. > > Finally, VisitorSupportsInvokeDynamic interface was removed, which broke > all FB visitors based on it via AbstractFrameModelingVisitor and 8 methods > were added to the Visitor interface. > > That's all I saw in our FB code (where we have lot of detectors), probably > others will report additional API breakage too, I can't say for sure. > > But main issue is the namespace change - it is really unnecessary and > surprising. I've read through the commons mailing list and I was surprised > that I saw no real request for it or any discussion about it (I haven't > read through all the years but around the namespace change last summer). > The only thing I saw was the Jira request > https://issues.apache.org/jira/browse/BCEL-222, out of nowhere, and few > commits later BCEL 6 API was made incompatible to every existing client. :-( > > > I'm a bit suprised that the BCEL API should affect the detectors, but > > perhaps there's a good reason for that. > > BF analyses bytecode, and although we have also few recently added ASM > based detectors (which are mostly BCEL free), most of the detectors (and > unfortunately many places in the FB API) use BCEL data structures. It was a > natural choice 15 years ago, where BCEL was the only one bytecode > framework... > > One way to "fix" the current FindBugs misery is to replace BCEL with ASM > (asm.tree package &Co) but this requires lot of effort because API and > design in ASM do not match BCEL 1:1 - and it will also break every FB > client in much harder way BCEL 6 API breakage does it today. Doing this > will effectively mean a complete fork/rewrite of FindBugs code, and no one > is willing to spend time for it. > > > > Question is: should we go this way? Alternative is: undo BCEL package > renaming and revert few API changes were made. This sounds complicated, but > is doable, see BCEL 6 fork where I renamed all packages back to the old > namespace in few minutes [7]. Fixing other "smaller" breaking BCEL API > changes is not that complicated either. However, it is also possible that > BCEL 6 will be released without breaking API's, if I understood right the > discussion on the apache commons-dev mailing list [8]. If anyone from BCEL > is listening to this mailing list, it would be nice to get some feedback on > BCEL 6 plans. > > > > I have done quite a bit of work trying to eliminate the API breaks > > without compromising the BCEL 6 updates. > > I really appreciate your effort. Please keep it going. > > > Though I have yet to revert the Java and Maven namespace changes as I > > wanted agreement with the approach first. > > > > From my point of view I would be happy to see a compatible version of > > BCEL using the original namespaces. > > I'm not sure what other Commons devs think. > > I hope to see a binary compatible BCEL 6 release, which is might be not > 1:1 drop-in replacement of BCEL 5 but at least 99%. Some changes must > happen, API must evolve, this is natural and no one can keep on the old API > forever. > But! After walking over the all BCEL renamings etc I do not really see a > real, functional reason to break *everything*, and a behavior change with > annotations parsing is something one can live with for a major release. Not > all detectors rely on annotations and BCEL behavior change can probably be > fixed in FB core code (so hidden from 3rd party libraries). > > > There are still some Java8/Java9 features that are not fully supported. > > This is true regardless of the namespace issue. > > That's absolutely fine and understandable. > > My main goal it to get rid of private BCEL forks which cannot be > rebuilt/updated anymore as we see it today, so that we can compile FB on > BCEL head, catching all the fixes you will provide in future BCEL > versions. ...And in my ideal world, the new FindBugs release based on BCEL > 6 will not break any existing 3rd party FindBugs detectors library, or > eventually only require a few trivial changes. > > Thanks! > > > > [0] https://github.com/findbugsproject/findbugs/commits/java9 > > > [1] https://github.com/findbugsproject/findbugs/issues/105 > > > [2] https://github.com/findbugsproject/findbugs/issues/106 > > > [3] https://issues.apache.org/jira/browse/BCEL-222 > > > [4] https://issues.apache.org/jira/browse/BCEL-273 > > > [5] https://github.com/findbugsproject/findbugs/commits/java9_bcel6 > > > [6] > https://github.com/findbugsproject/findbugs/commit/f9f46bf97c47f011e3757bf9904249faf1039239 > > > [7] https://github.com/iloveeclipse/commons-bcel/commits/old_structure > > > [8] > http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/thread > > > > > > On Sunday 05 June 2016 12:55 Andrey Loskutov wrote: > > >> Hi all, > > >> > > >> I've got some free time and now working on Java 9 support for > FindBugs, > > >> the first draft works already, but need some more polishing. > > >> > > >> The main goal is to support FB running on Java 9 JRE, to support > reading > > >> Java 9 class files, and to support FB running on Java 8 but analyzing > > >> Java 9 code. Nice to have (but not in my scope right now) is to > support > > >> any new Java 8/9 constructs like lambdas, type annotations etc. > > >> > > >> I've documented briefly tasks coming to my mind via [1]. > > >> > > >> I plan to push my changes on new java9 branch ASAP. > > >> > > >> Main discussion points I see so far: > > >> > > >> 1) We must bump the required JRE for FB to 1.8. I see no reason trying > > >> to support obsoleted 1.7 JRE. If someone wants run FB on 1.7, the old > FB > > >> 3.0.1 should be used. Objections? > > >> > > >> 2) Since there are no official releases from ASM/BCEL with Java 9 > > >> support yet, we can release first version based on our own FB private > > >> snapshot versions. The maven folks will cry but this is a chicken and > > >> egg problem, so I don't care about maven support for the first round > (of > > >> course any help is welcome). Objections? > > >> > > >> 3) Due the JRE version bump I would propose to bump FB version to > 3.1.0. > > >> Objections? > > >> > > >> Please give your feedback either on the lists or on the github task > [1]. > > >> > > >> [1] https://github.com/findbugsproject/findbugs/issues/105 > > >> > > > > > > -- > > > Kind regards, > > > google.com/+AndreyLoskutov > > > _______________________________________________ > > > Findbugs-discuss mailing list > > > findbugs-disc...@cs.umd.edu > > > https://mailman.cs.umd.edu/mailman/listinfo/findbugs-discuss > > -- > Kind regards, > google.com/+AndreyLoskutov > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
