Live data from Hacker News

FindBugs project in its current form is dead

mailman.cs.umd.edu

101–110 of 121 posts

Re: FindBugs project in its current form is dead

#101
post #71

Earlier quoted context omitted.

Technically, it's not a compiler plugin - it actually replaces javac by extending JavaCompiler, wrapping it and applying additional verifications without altering the output. Effectively it's introducing its own API for compiler plugins, with those being the checks, very much akin to APT. See https://github.com/google/error-prone/blob/master/core/src/m... for the entry-point. I'm very close to getting out of my depth…

This is not close to a plugin. I don't see why the term plugin is used here. This is misleading people into believing error-prone is using a supported API. I also don't see how it is "very much akin to APT". APT is an API where the A stands for abstract and the I stands for interface. APT therefore is portable across compilers and supported. error-prone seems to be tied to the current implementation of javac. It is a…

The distinction I was trying to make was one between where in the toolchain it lives: error-prone is part of compilation, whereas Findbugs is after-the-fact.

Error-prone is a compiler plugin _mechanism_ - once you have an error-prone compiler, the checks are arguments to the compiler just like APT annotation processors are.

It's built on a standard API - the JavaCompiler mechanism built into the Java SDK - but yes, the code does have further dependencies on com.sun packages. This is a little confusing because why expose the compiler for invocation and extension when extensions have to rely on unsupported code?

So, yes, there are ways where the distinction is important, but they're orthogonal to the point I was trying to make.

Re: FindBugs project in its current form is dead

#102
post #67

Earlier quoted context omitted.

It's still not a good sign that it took this level of public attention to get you to reply to the active community on their urgent needs.

^ this. There is absolutely no reason to not be answering emails, even if to say, "I'm really swamped, and need help." I don't mean to denigrate you, but I must be candid here: hoarding admin rights so that only you have them and no one else can get any work done is simply not acceptable in a team environment. Going forward, I would recommend taking a look through other projects you may be involved with, and make sur…

> There is absolutely no reason to not be answering emails

Sometimes there is.

You can express your disappointment in how a project is managed without implying that someone else isn't living their life properly.

Re: FindBugs project in its current form is dead

#103

Earlier quoted context omitted.

I don't know why you are being downvoted, but I agree with you. The level of entitlement expressed on this forum is off the charts. This behavior is reflected in this case or in case of RethinkDB or any other startup which is closing down, where the frame of mind or needs of the people who build/maintain are secondary to those of customer/users. Its quite a paradox.

> The level of entitlement expressed on this forum is off the charts. This is ridiculous. Expecting the maintainer who hasn't contributed for over a year (hasn't given any life signs or shown any interest) to give admin rights to someone who genuinely cares about the project isn't entitlement. It's the absolute minimum he could do to keep the project alive at the expense of other peoples time and effort.

Not really. People die unexpectedly. Things come up. Adopting a project with a bus factor of one and expecting things to just work out, and blaming that person instead of yourself when they don't... I think that's pretty close to "entitlement", with a dash of wishful thinking.

Re: FindBugs project in its current form is dead

#104

Earlier quoted context omitted.

Error-prone is somewhat tied to a specific version of the Java compiler -- so you need Javac 8, but you can set --source to an older version of the language. If the newer Javac does not emit bytecode that works with your runtime, you can run two compiles (one error-prone for the errors, one production compile with whatever compiler you need).

Haven't we learnt several times in the past that this is a bad idea? Eg. with Android or GAE/J. This is going to require a lot of effort for every upcoming Java release delaying support for a long time, again see Android or GAE/J. It also makes integration with Eclipse difficult at best.

It depends on what you mean by "bad idea". You've got three choices, basically: analyse source, analyse the AST, or analyse bytecode. There are advantages and disadvantages of each approach, but for what Google's trying to do - allow people to write their own checks - there are clear advantages to analysing the AST.

I've written checks in both error-prone and Findbugs and error-prone is simply more natural. Part of that is the Findbugs API, for want of a better word, is godawful, but the AST is simply the best representation of the program for analysis.

If you're going to analyse the AST, you then have a further two choices: build your own AST, or hook into the compiler. Building it yourself is dangerous here: firstly, it's repeating a lot of work that's already been done, but more importantly you want to be absolutely sure that what you're analysing is what you're actually building. Either way you have to do updates when the language changes, as any static analysis tool needs to.

Are there costs to this decision? Yep. Is it going to be the right tool for every job? Nope. But that doesn't mean that these decisions don't have reasoning behind them, and compelling reasons to go this way.

Re: FindBugs project in its current form is dead

#105

Earlier quoted context omitted.

He didn't demand "work", he simply pointed out that hibernating or abandoning a project many people have come to rely on without arranging for others to (at least temporarily) take over is irresponsible and causes a lot of frustration.

Answering emails is work. It's also often a lot harder than it sounds at first blush.

Setting up auto-reply takes 10 minutes. All modern email clients allow creating auto-reply rules based on who the email is from or the words the subject line or body contain.

"Thank you for your email. This is an automated reply to let you know that active development of this project is currently on hold. If you have any questions, please email bob@project.com, who is the current maintainer."

That's it.

Re: FindBugs project in its current form is dead

#106

Earlier quoted context omitted.

> The level of entitlement expressed on this forum is off the charts. This is ridiculous. Expecting the maintainer who hasn't contributed for over a year (hasn't given any life signs or shown any interest) to give admin rights to someone who genuinely cares about the project isn't entitlement. It's the absolute minimum he could do to keep the project alive at the expense of other peoples time and effort.

Not really. People die unexpectedly. Things come up. Adopting a project with a bus factor of one and expecting things to just work out, and blaming that person instead of yourself when they don't... I think that's pretty close to "entitlement", with a dash of wishful thinking.

Look, open-source projects may be "free" in the sense that you don't pay money for them, but they still cost time. Time to learn, time to integrate into your project, time to debug if things go wrong. Not to mention time to switch to another library if the one you picked doesn't work out for some reason.

As such, there exists a kind of implied social contract between the project owner and users. The owner wants people to use the library[1] and improve it, and the users in turn want semi-frequent updates/fixes and to be informed about the status of the project. Projects that are regularly updated receive more users and contributors, who in turn help provide bug reports, improvement ideas and PRs.

Calling users "entitled" for asking the owners to adhere to the aforementioned social contract, which defines open-source and holds it together like glue, betrays a fundamental lack of understanding of what this ecosystem is and how it manages to be a legitimate alternative to commercial software.

[1]If the owner has other reasons for putting up the project on Github/Gitlab etc (e.g. it's their hobby project, or they want to showcase their code to potential employers), and has no intention to support it, then they should include a note in the readme that the code is not intended for production use. Problem solved.

Re: FindBugs project in its current form is dead

#107
post #75

Earlier quoted context omitted.

You must have paid 4 digits or more for his services then? Otherwise I think you can't demand any attention at all and be happy if you receive it.

I have been involved in open source and non-commercial, volunteer driven projects for at least a decade. It's true that it's not right to demand volunteers who spend their time on the projects to answer questions. However, in this case, having read the mailing list thread and even the parent post to which you replied, I don't believe anyone is _demanding_ anything from the project owner. People who are passionate abo…

I agree with all you say. And I also understand being angry about a project for not considering me as a user enough.

However, "There is absolutely no reason to not be answering emails" gave me the impression that at least one person is demanding replies to emails. I still feel it's okay to tell the quoted person that if he doesn't pay someone he can't demand from that person to answer emails.

Last but not least, if someone hasn't answered emails for some time, who seemingly had enough trust before to be important in a software project, then it may be wise, even for people with legit demands, to see whether or not that person had good reasons for his absense or not.

Re: FindBugs project in its current form is dead

#108

Earlier quoted context omitted.

Not really. People die unexpectedly. Things come up. Adopting a project with a bus factor of one and expecting things to just work out, and blaming that person instead of yourself when they don't... I think that's pretty close to "entitlement", with a dash of wishful thinking.

Look, open-source projects may be "free" in the sense that you don't pay money for them, but they still cost time. Time to learn, time to integrate into your project, time to debug if things go wrong. Not to mention time to switch to another library if the one you picked doesn't work out for some reason. As such, there exists a kind of implied social contract between the project owner and users. The owner wants peopl…

Open source software runs the gamut from unmaintained to supported by a foundation with multiple corporate members, a board, and plans in place to ensure continuity under various adverse circumstances. How much stability do you need?

It isn't the responsibility of the project owner to tell you that their project doesn't meet your needs. It is your responsibility to check how the project is run and choose whether or not to take on that risk.

People actually doing the work of evaluating the risks they are taking on is how open source actually does become a legitimate (sometimes safer) alternative to commercial software.

People not doing the work, taking on risk without doing their homework, and then whining when it bites them in the ass is, well, "the story of left-pad".

Re: FindBugs project in its current form is dead

#109
post #100
post #59

Earlier quoted context omitted.

Coverity Scan is a marketing tool. As for FindBugs integration... The majority of Coverity issues I deal with are labelled as FindBugs issues.

I'm curious, why don't you run findbugs directly rather than (I presume) paying Coverity?

I would, but the business still pays Coverity and I have to regularly check Coverity reports.

Simple subordination.

Re: FindBugs project in its current form is dead

#110

Earlier quoted context omitted.

Error-prone is somewhat tied to a specific version of the Java compiler -- so you need Javac 8, but you can set --source to an older version of the language. If the newer Javac does not emit bytecode that works with your runtime, you can run two compiles (one error-prone for the errors, one production compile with whatever compiler you need).

Haven't we learnt several times in the past that this is a bad idea? Eg. with Android or GAE/J. This is going to require a lot of effort for every upcoming Java release delaying support for a long time, again see Android or GAE/J. It also makes integration with Eclipse difficult at best.

[deleted]
Post reply on HN