-
Notifications
You must be signed in to change notification settings - Fork 34
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
Consider a bundleded signature set that would suggest replacing HashMap, HashSet, Collectors.toSet, Collectors.toMap with Linked alternatives for deterministic oder #199
Comments
Technically this is easy to do. With forbiddenapis 3.3 it is also now easier to forbid all overloads of a method. You can also forbid the whole class, but this may lead to problems with API signatures expecting those classes. I am not sure if this should be shipped with forbiddenapis. Maintaining the existing signatures is painful already. If one would publish the signatures on Maven Central as artifacts, one can easily use them in Maven, there's direct support to link to them. In Gradle it also works but not as intuitive. A signature file could look like:
I'd suggest to put something like this into your own build. |
For instance,
Here's how I put the signatures for now, however, I would say, it took me significantly more time than I wanted, mainly because the signature file does not support things like "if (java10+)". jqwik-team/jqwik@0c3f049 (it is the part of the PR348 which I mention in the first comment) |
HashSet
,HashMap
,Collectors.toSet()
, and similar APIs do not keep the element order, and it might result in surprising and unexpected results.What if error-prone could catch those types of errors and suggest replacing the calls via
LinkedHash*
?See jqwik-team/jqwik#348
See google/error-prone#3230
The text was updated successfully, but these errors were encountered: