Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers
A classic Monty Python "I'm not dead yet!" Gary On Mon, Nov 7, 2016 at 11:23 AM, Bruno P. Kinoshita < brunodepau...@yahoo.com.br.invalid> wrote: > I think the maintainer of FindBugs replied yesterday to the HackerNews > thread > https://news.ycombinator.com/item?id=12885549 > > Looks like there will be some activity in the next weeks :) hopefully > someone > else will be added as project admin too > > Bruno > > > > > - Original Message - > > From: Stian Soiland-Reyes > > To: Commons Developers List > > Sent: Monday, 7 November 2016 6:32 AM > > Subject: FindBugs project announced as 'dead', blaims code rot and lack > of maintainers > > > > See > > https://mailman.cs.umd.edu/pipermail/findbugs-discuss/ > 2016-November/004321.html > > > > In particular the author is not happy about the BCEL integration: > > > >> The other major reasons for the FindBugs current bad state: > >> > >> 1) The code is very complex, has "organically grown" over a > > decade, is > >> not documented and has poor public interfaces. Most of the code > consists > >> of the very low level bytecode related stuff, tightly coupled with the > >> ancient BCEL library, which doesn't scale and is not multi-thread safe. > >> No one enjoys maintaining this code, at least not me. I see no future > >> for FindBugs with the BCEL approach, and see no way to get rid of it > >> without investing lot of effort, and without breaking every detector > and > >> possibly many 3rd party tools. This is the biggest issue we have with > >> FindBugs today, and most likely the root cause for all the evil. This > >> code can't be fixed, it must be rewritten. > > > > ..but the main problem seems to be lack of maintaners. > > > > > > -- > > Stian Soiland-Reyes > > http://orcid.org/-0001-9842-9718 > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers
I think the maintainer of FindBugs replied yesterday to the HackerNews thread https://news.ycombinator.com/item?id=12885549 Looks like there will be some activity in the next weeks :) hopefully someone else will be added as project admin too Bruno - Original Message - > From: Stian Soiland-Reyes > To: Commons Developers List > Sent: Monday, 7 November 2016 6:32 AM > Subject: FindBugs project announced as 'dead', blaims code rot and lack of > maintainers > > See > https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004321.html > > In particular the author is not happy about the BCEL integration: > >> The other major reasons for the FindBugs current bad state: >> >> 1) The code is very complex, has "organically grown" over a > decade, is >> not documented and has poor public interfaces. Most of the code consists >> of the very low level bytecode related stuff, tightly coupled with the >> ancient BCEL library, which doesn't scale and is not multi-thread safe. >> No one enjoys maintaining this code, at least not me. I see no future >> for FindBugs with the BCEL approach, and see no way to get rid of it >> without investing lot of effort, and without breaking every detector and >> possibly many 3rd party tools. This is the biggest issue we have with >> FindBugs today, and most likely the root cause for all the evil. This >> code can't be fixed, it must be rewritten. > > ..but the main problem seems to be lack of maintaners. > > > -- > Stian Soiland-Reyes > http://orcid.org/-0001-9842-9718 > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers
Gary Gregory schrieb am So., 6. Nov. 2016 um 19:00 Uhr: > The whole post is interesting. Sounds like a fork is inevitable. So much > work though... > There already is a fork. See [1] Benedikt [1] https://github.com/spotbugs/spotbugs > > Gary > > On Nov 6, 2016 9:32 AM, "Stian Soiland-Reyes" wrote: > > > See > > https://mailman.cs.umd.edu/pipermail/findbugs-discuss/ > > 2016-November/004321.html > > > > In particular the author is not happy about the BCEL integration: > > > > > The other major reasons for the FindBugs current bad state: > > > > > > 1) The code is very complex, has "organically grown" over a decade, is > > > not documented and has poor public interfaces. Most of the code > consists > > > of the very low level bytecode related stuff, tightly coupled with the > > > ancient BCEL library, which doesn't scale and is not multi-thread safe. > > > No one enjoys maintaining this code, at least not me. I see no future > > > for FindBugs with the BCEL approach, and see no way to get rid of it > > > without investing lot of effort, and without breaking every detector > and > > > possibly many 3rd party tools. This is the biggest issue we have with > > > FindBugs today, and most likely the root cause for all the evil. This > > > code can't be fixed, it must be rewritten. > > > > ..but the main problem seems to be lack of maintaners. > > > > > > -- > > Stian Soiland-Reyes > > http://orcid.org/-0001-9842-9718 > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers
Looks like Bill Pugh was woken up: https://twitter.com/wpugh/status/795350364291813376 2016-11-06 19:00 GMT+01:00 Gary Gregory : > The whole post is interesting. Sounds like a fork is inevitable. So much > work though... > > Gary > > On Nov 6, 2016 9:32 AM, "Stian Soiland-Reyes" wrote: > > > See > > https://mailman.cs.umd.edu/pipermail/findbugs-discuss/ > > 2016-November/004321.html > > > > In particular the author is not happy about the BCEL integration: > > > > > The other major reasons for the FindBugs current bad state: > > > > > > 1) The code is very complex, has "organically grown" over a decade, is > > > not documented and has poor public interfaces. Most of the code > consists > > > of the very low level bytecode related stuff, tightly coupled with the > > > ancient BCEL library, which doesn't scale and is not multi-thread safe. > > > No one enjoys maintaining this code, at least not me. I see no future > > > for FindBugs with the BCEL approach, and see no way to get rid of it > > > without investing lot of effort, and without breaking every detector > and > > > possibly many 3rd party tools. This is the biggest issue we have with > > > FindBugs today, and most likely the root cause for all the evil. This > > > code can't be fixed, it must be rewritten. > > > > ..but the main problem seems to be lack of maintaners. > > > > > > -- > > Stian Soiland-Reyes > > http://orcid.org/-0001-9842-9718 > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers
The whole post is interesting. Sounds like a fork is inevitable. So much work though... Gary On Nov 6, 2016 9:32 AM, "Stian Soiland-Reyes" wrote: > See > https://mailman.cs.umd.edu/pipermail/findbugs-discuss/ > 2016-November/004321.html > > In particular the author is not happy about the BCEL integration: > > > The other major reasons for the FindBugs current bad state: > > > > 1) The code is very complex, has "organically grown" over a decade, is > > not documented and has poor public interfaces. Most of the code consists > > of the very low level bytecode related stuff, tightly coupled with the > > ancient BCEL library, which doesn't scale and is not multi-thread safe. > > No one enjoys maintaining this code, at least not me. I see no future > > for FindBugs with the BCEL approach, and see no way to get rid of it > > without investing lot of effort, and without breaking every detector and > > possibly many 3rd party tools. This is the biggest issue we have with > > FindBugs today, and most likely the root cause for all the evil. This > > code can't be fixed, it must be rewritten. > > ..but the main problem seems to be lack of maintaners. > > > -- > Stian Soiland-Reyes > http://orcid.org/-0001-9842-9718 > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers
The problem is the admin/owner has left and refuses to give access to anyone else. The team has already decided to hard - fork, and is working to get set up. Anyone interested in joining is welcome. Contact me if interested. On 11/06/2016 12:32 PM, Stian Soiland-Reyes wrote: See https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004321.html In particular the author is not happy about the BCEL integration: The other major reasons for the FindBugs current bad state: 1) The code is very complex, has "organically grown" over a decade, is not documented and has poor public interfaces. Most of the code consists of the very low level bytecode related stuff, tightly coupled with the ancient BCEL library, which doesn't scale and is not multi-thread safe. No one enjoys maintaining this code, at least not me. I see no future for FindBugs with the BCEL approach, and see no way to get rid of it without investing lot of effort, and without breaking every detector and possibly many 3rd party tools. This is the biggest issue we have with FindBugs today, and most likely the root cause for all the evil. This code can't be fixed, it must be rewritten. ..but the main problem seems to be lack of maintaners. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
FindBugs project announced as 'dead', blaims code rot and lack of maintainers
See https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-November/004321.html In particular the author is not happy about the BCEL integration: > The other major reasons for the FindBugs current bad state: > > 1) The code is very complex, has "organically grown" over a decade, is > not documented and has poor public interfaces. Most of the code consists > of the very low level bytecode related stuff, tightly coupled with the > ancient BCEL library, which doesn't scale and is not multi-thread safe. > No one enjoys maintaining this code, at least not me. I see no future > for FindBugs with the BCEL approach, and see no way to get rid of it > without investing lot of effort, and without breaking every detector and > possibly many 3rd party tools. This is the biggest issue we have with > FindBugs today, and most likely the root cause for all the evil. This > code can't be fixed, it must be rewritten. ..but the main problem seems to be lack of maintaners. -- Stian Soiland-Reyes http://orcid.org/-0001-9842-9718 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
