When a job's execution policy is null, it means the job will accept all nodes. I will update the documentation and javadoc to clarify this.

I'm not sure I understand the use case for a "reject all" policy. Is this to be used as a convenience, to easily disable parts of complex policies?

When a job's execution policy is null, it means the job will accept all
nodes. I will update the documentation and javadoc to clarify this.

True - but this applies only to job's execution policy, and not to policy itself. In many other places you cannot, and shouldn't, use null as "empty policy". Like - OrRule/AndRule doesn't handle null as "accept all".

I actually was quite suprised that

PolicyParser.parsePolicy(...)

returns null for empty policy. So

new OrRule(PolicyParser.parsePolicy("<executionPolicy></executionPolicy>"))

will throw NPE.

I agree on RejectAll - you can always have Not(AcceptAll) - assuming positive one is there :). As "no policy applied" means "accept all" - it seems ok even to name it "empty" policy.

Finally - adding "empty" element, your policy algebra becomes monoid (so one will be able to fold on it).

And as always - world without nulls is much nicer. Null is something like unchecked exception in java. Everyone knows it can appear here and there, but you are always suprised when this actually happens :P.

marcin

There is indeed an inconsistency between the policy validation, which will throw an exception on an empty policy, and the policy parsing, which will not and returns a null policy instead. I am fixing that.

There is also the problem of missing arguments checks for execution policy rules constructors, for which I registered a separate Bug report JPPF-555 - No argument checking in execution policies constructors.

Regarding RejectAll, I finally decided to implement it. If we want to make things convenient, we might as well make them as convenient as possible.