In AccessEvaluator, there is a small type called Authorizer that allows users to plug in an object that determines whether an entity being evaluated has an authorization or not. This is basically just a Predicate<String> and can be replaced by that.
HAS_AUTH_PREDICATE.test("someAuth");
// is basically the same as
HAS_AUTH_AUTHORIZER.isAuthorized("someAuth");
The main difference is that Predicates can be much more easily composed using and and or, and works better with all the Java Functional ecosystem. There is an argument to be had for granting a new convenience name to an equivalent functional object. But, I don't think it adds much here, and even if it did, it could at least extend Predicate<String> with a default method, so either way of calling could be used. But, I still think we could probably just get rid of it entirely, since Predicate<String> by itself does the job well enough.
In AccessEvaluator, there is a small type called
Authorizer
that allows users to plug in an object that determines whether an entity being evaluated has an authorization or not. This is basically just aPredicate<String>
and can be replaced by that.The main difference is that Predicates can be much more easily composed using
and
andor
, and works better with all the Java Functional ecosystem. There is an argument to be had for granting a new convenience name to an equivalent functional object. But, I don't think it adds much here, and even if it did, it could at least extendPredicate<String>
with a default method, so either way of calling could be used. But, I still think we could probably just get rid of it entirely, sincePredicate<String>
by itself does the job well enough.