The current behavior of PKIXParameters.setRevocationEnabled when a PKIXRevocationChecker is passed in is not very clear, and could be improved.

Currently, if you pass in a PKIXRevocationChecker (to PKIXParameters.addCertPathChecker or PKIXParameters.setCertPathCheckers), it means that the PKIX provider will use this as its revocation mechanism to check revocation, regardless of the setting of PKIXParameters.isRevocationEnabled. This is only mentioned in the PKIXRevocationChecker class summary:

"When supplying a revocation checker in this manner, it will be used to
check revocation irrespective of the setting of the RevocationEnabled
flag."

However, this is inconsistent with the specification of PKIXParameters.setRevocationEnabled which says:

"Sophisticated applications should set this flag to false when it is not
practical to use a PKIX service provider's default revocation checking
mechanism or when an alternative revocation checking mechanism is to be
substituted (by also calling the addCertPathChecker or
setCertPathCheckers methods)."

Furthermore, the text in PKIXRevocationChecker could be improved as it's not clear if the default RevocationChecker will also still be called (if revocation is enabled) or if only this one will be called.

Some of this has to do with overloading the revocationEnabled boolean value to mean too many things. It might make more sense to have a new setRevocationEnabled(PKIXRevocationChecker) method.