Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Warn about use of methods that might block indefinitely #35

Open
ankon opened this issue Jul 6, 2015 · 2 comments
Open

RFC: Warn about use of methods that might block indefinitely #35

ankon opened this issue Jul 6, 2015 · 2 comments

Comments

@ankon
Copy link
Contributor

ankon commented Jul 6, 2015

This is more of an idea than an actual issue, so by all means shoot me down :)

Basically I'm currently reading through 'Release It' (http://www.amazon.com/dp/0978739213/), and one of the stability anti-patterns there is to not have proper timeouts (and handling of those). At least some of those are caused by the use of methods such as Object#wait(), so I was wondering whether modernizer could not help with that issue by flagging those uses (and suggest to use methods with a timeout).

Now, some issues I see immediately:

  1. There might be reviewed-and-approved uses of those methods, so there needs to be an easy way to mark those as acceptable. (see disable Modernizer via @SuppressWarnings annotation #3)
  2. Not every user of modernizer might want to have those checks, especially since fixing the issues can be quite a bit of work, so it would be good to have those in a separate, optional, rules set (see Allow multiple violations files #22)
  3. Coming up with a list of those methods will be quite some work as well: It's not just synchronization methods, but for example also things like Sockets, URL connections, Jersey clients ... and for some of those the way to set a timeout is with an additional method call.

What do you think? Is this a realistic use for modernizer, or is it too far out-of-scope?

@gaul
Copy link
Owner

gaul commented Jul 8, 2015

I think laying the foundation with #22 would be the best way to start this. That way users can experiment with the suggested violations and we can get some feedback on more popular anti-patterns.

@metteo
Copy link

metteo commented Dec 4, 2019

@ankon I know this discussion is 4 years old but IMHO the rules you describe should be part of PMD Java Rules

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants