FindBugs project announced as 'dead', blaims code rot and lack of maintainers

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

FindBugs project announced as 'dead', blaims code rot and lack of maintainers

Stian Soiland-Reyes
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/0000-0001-9842-9718

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers

Dave Brosius-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers

garydgregory
In reply to this post by Stian Soiland-Reyes
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" <[hidden email]> 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/0000-0001-9842-9718
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers

Timo-2
Looks like Bill Pugh was woken up:
https://twitter.com/wpugh/status/795350364291813376

2016-11-06 19:00 GMT+01:00 Gary Gregory <[hidden email]>:

> 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" <[hidden email]> 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/0000-0001-9842-9718
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers

Benedikt Ritter-4
In reply to this post by garydgregory
Gary Gregory <[hidden email]> 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" <[hidden email]> 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/0000-0001-9842-9718
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers

Bruno P. Kinoshita-3
In reply to this post by Stian Soiland-Reyes
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 <[hidden email]>
> To: Commons Developers List <[hidden email]>
> 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/0000-0001-9842-9718
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers

garydgregory
A classic Monty Python "I'm not dead yet!"

Gary

On Mon, Nov 7, 2016 at 11:23 AM, Bruno P. Kinoshita <
[hidden email]> 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 <[hidden email]>
> > To: Commons Developers List <[hidden email]>
> > 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/0000-0001-9842-9718
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
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