Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FindBugs project in its current form is dead

mailman.cs.umd.edu

Post reply on HN
Print view View original

111–120 of 121 posts

Re: FindBugs project in its current form is dead

#111

Post by Afty »

needusername wrote: post #99
Seol wrote: 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 standard annotation processing APIs don't provide enough information to do the analyses we want to do, so we do hook into javac internals.

It does require a lot of effort to keep up with OpenJDK updates, but that's my team's job, and we have to do the work anyway to keep Error Prone running inside Google. We tie Error Prone to a specific version of javac, which matches the one we are currently using inside Google (https://github.com/google/error-prone-javac), so we don't have to support multiple different internal APIs. We are currently using a version of javac 9 from about a year ago, and we're planning a bump to something close to head maybe in Q1.

Eclipse integration would be a pain but would look a lot like what the Checker Framework does.

Re: FindBugs project in its current form is dead

#112

Post by Afty »

jbangert wrote: post #57
nothrabannosir wrote: post #44

Earlier quoted context omitted.

> current error-prone releases only work with Java 8 I'm assuming that means it will only run on the JVM8, but it can analyze any version of Java code?

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).

We package a specific revision of javac and use it for Error Prone. Currently this is a ~year old version of javac 9, which means that:

1) You have to execute your compiler on JDK >=8.

2) You cannot target bytecode <= Java 5.

Re: FindBugs project in its current form is dead

#113

Post by aseipp »

enraged_camel wrote: post #106
inimino wrote: post #103

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…

> As such, there exists a kind of implied social contract between the project owner and users.

No, there doesn't. The "reality" is this: you are using the code I have given out, and that's all you get from me.

I also very much enjoy how you talk about your own free time, and how it's not really "free" to evaluate this stuff, and thus there's a burden etc etc -- and then conveniently turn around immediately and say "but maintainers are required to give me their time, that's part of the social contract". What kind of bullshit is this? It's always the same shit -- time and money for me (I get to reap the rewards, shitpost on your bugtracker, and complain on my blog when you make me mad), none for thee (you're required to help me).

If you're so worried about your own time and your own cost savings -- go buy proprietary code. Or pay the maintainer. Then you can actually have a real contract without handwaving and appealing to non-existent "social contracts".

If you want to whine about taking on risk, maybe you should also bear the burdens of that, as well as the benefits. I'm sorry that's so unfair, but maybe it could teach you something.

> 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.

So your answer is that we should always assume this "social contract" exists with every piece of code, and thus maintainers are obligated to slave away for us unless specified otherwise?

This entire post reeks of nonsense entitlement-justification. I do not owe you my free time because I posted a library on GitHub, though I may choose to give you my time. I am also free to rescind that offer at any time, and guess what -- I do not need your approval to do so (because, really, you are not that important). End of story.

Re: FindBugs project in its current form is dead

#114

Post by Afty »

sdegutis wrote: post #5

Interestingly, the spirit of the FindBugs project lives on in the development of languages like Rust and Swift, considering the purpose of the FindBugs project is to fix inherent flaws in Java, e.g. not having a way to determine whether something will be null, or not telling you whether you checked whether something will be null at runtime, etc.

You're getting some flack for this, but I agree with you based on what we've seen with Error Prone. The people who design programming languages are human, and they make mistakes. Unfortunately, if your language becomes successful, it becomes nearly impossible to fix these mistakes while retaining backwards compatibility.

Many of our checks are essentially working around problems with the language or API design. For example, our ForOverride checker (http://errorprone.info/bugpattern/ForOverride) addresses the fact that existing Java visibility modifiers are not expressive enough for some things the Guava team wanted to do. Our HashtableContains checker (http://errorprone.info/bugpattern/HashtableContains) addresses an issue with a poorly-named method in the old Hashtable API, which really should be deprecated but is infeasible given the old code that uses it.

Re: FindBugs project in its current form is dead

#115

Post by enraged_camel »

aseipp wrote: post #113
enraged_camel wrote: post #106

Earlier quoted context omitted.

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…

> As such, there exists a kind of implied social contract between the project owner and users. No, there doesn't. The "reality" is this: you are using the code I have given out, and that's all you get from me. I also very much enjoy how you talk about your own free time, and how it's not really "free" to evaluate this stuff, and thus there's a burden etc etc -- and then conveniently turn around immediately and say "b…

>>No, there doesn't. The "reality" is this: you are using the code I have given out, and that's all you get from me.

Fine, then say so on the readme file! It's not lack of updates people are worried about. It's the uncertainty that comes with not knowing whether the owner intends to continue developing it or if they have abandoned it. If you pay some attention, you'll see that's what this entire conversation is about: the owner of a popular project being the single point of failure and then going missing.

>>I do not owe you my free time because I posted a library on GitHub, though I may choose to give you my time. I am also free to rescind that offer at any time, and guess what -- I do not need your approval to do so (because, really, you are not that important). End of story.

Again, no one is asking for your free time. If you don't want to update the project or push fixes, fine, whatever. The only thing people are asking you to do is to transfer ownership of the project - or at least admin/maintainer rights - to someone else in a responsible manner if you decide to abandon it. You may call this "entitlement." I call it "being an adult."

And frankly, get over yourself. You aren't that important either. Just because you posted a piece of shitty code on Github doesn't give you the right to act like an asshole when people come to rely on that code. Try not to let it get to your head too much, mmkay?

Re: FindBugs project in its current form is dead

#116

Post by needusername »

Seol wrote: post #104
needusername wrote: post #70

Earlier quoted context omitted.

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 t…

I am not questioning the AST approach. I'm questioning the approach of hooking into JDK internals and using JDK internals as an interface for custom check implementations.

Google has done similar things several times in the past (GWT, GAE/J, Android) and every time updates to the latest Java required a lot of effort, were therefore late and eventually abandoned.

Re: FindBugs project in its current form is dead

#117

Post by needusername »

Afty wrote: post #111
needusername wrote: post #99

Earlier quoted context omitted.

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 standard annotation processing APIs don't provide enough information to do the analyses we want to do, so we do hook into javac internals. It does require a lot of effort to keep up with OpenJDK updates, but that's my team's job, and we have to do the work anyway to keep Error Prone running inside Google. We tie Error Prone to a specific version of javac, which matches the one we are currently using inside Google…

This is all fine and good if you're a Google internal user who gets support form your team. Things are a bit different if you're a user from outside of Google.

Re: FindBugs project in its current form is dead

#118

Post by mkobit »

TD-Linux wrote: post #97
mkobit wrote: post #35

Further on in the email chain, it looks like there is momentum for hard forking under another project named 'SpotBugs' [1, 2]. I hope to see the project live on as it has been useful. Other tools like Google's Error Prone and IntelliJ's inspection toolset are awesome, and FindBugs is complimentary to them. [1] https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-N... [2] https://github.com/spotbugs/spotbugs

Side note: "hard fork" has a special meaning for Bitcoin and derivatives, but no meaning for a software fork. I've seen that phrase used several times in the comments though - is this a new trend?

I'm not familiar with Block chain terminology, so I was not aware of the collision.

A previous response in the thread [1] also contains "hard fork", which is probably why I and possibly others have repeated it here.

It could be a trend, but my differentiation (here at least) is that a "hard" fork means that the maintainers themselves are splitting from the original project while also forking the original code base.

It would probably make more sense to just call it a "fork" :).

[1]: https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2016-N...

Re: FindBugs project in its current form is dead

#119

Post by inimino »

enraged_camel wrote: post #115
aseipp wrote: post #113

Earlier quoted context omitted.

> As such, there exists a kind of implied social contract between the project owner and users. No, there doesn't. The "reality" is this: you are using the code I have given out, and that's all you get from me. I also very much enjoy how you talk about your own free time, and how it's not really "free" to evaluate this stuff, and thus there's a burden etc etc -- and then conveniently turn around immediately and say "b…

>>No, there doesn't. The "reality" is this: you are using the code I have given out, and that's all you get from me. Fine, then say so on the readme file! It's not lack of updates people are worried about. It's the uncertainty that comes with not knowing whether the owner intends to continue developing it or if they have abandoned it. If you pay some attention, you'll see that's what this entire conversation is about…

> Fine, then say so on the readme file!

Understanding that a project with a single maintainer may become unmaintained unexpectedly should be common sense.

> Again, no one is asking for your free time.

You literally are. Including the time and energy needed to decide whether or not to continue maintaining the project, and to hand it off in an appropriate way.

> Just because you posted a piece of shitty code on Github doesn't give you the right to act like an asshole when people come to rely on that code.

Is this normally the tone you take when asking people who helped you to keep helping you?

Just because you randomly downloaded some code from Github and chose to rely on it doesn't mean the author owes you a damn thing. Don't like it? Fork it. That actually is how open source works.

Re: FindBugs project in its current form is dead

#120

Post by AstralStorm »

inimino wrote: post #102
dmuth wrote: post #67

Earlier quoted context omitted.

^ 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.

Yes, we all need to prevent speaking to prevent implications. ;)

Or are you implying the author is so thin skinned he cannot take a bit of judgement?

Post reply on HN