This wouldn't be a linter that would be enabled by default, or with any rules configured OOTB.
The idea is that Java APIs can sometimes be confusingly large. Teams can settle on what a "sane subset" of those APIs would be, and then enforce it.
A couple practical examples that come to mind:
encouraging raw Kafka interop instead of a Clojure wrapper
encouraging java.util.concurrent.BlockingQueues over other alternatives.
These APIs can have an abundance of methods/arities. One could define what the "good arities" would be on a per-project manner, and ban anything else from the same Java package (or class).
My thinking is that this linter would make certain architectural choices far more viable than they are today.
(Eastwood)
This wouldn't be a linter that would be enabled by default, or with any rules configured OOTB.
The idea is that Java APIs can sometimes be confusingly large. Teams can settle on what a "sane subset" of those APIs would be, and then enforce it.
A couple practical examples that come to mind:
These APIs can have an abundance of methods/arities. One could define what the "good arities" would be on a per-project manner, and ban anything else from the same Java package (or class).
My thinking is that this linter would make certain architectural choices far more viable than they are today.