`NimbusJwtDecoder` should remove its setters in favor of its builders

This is perhaps a little controversial, but I've sometimes wondered about the possibility of converting some of the more commonly used setters to return this rather than void.

Case in point, I recently wanted to be able to do something like this:

@Bean
ReactiveJwtDecoder jwtDecoder(/* ... */) {
    return NimbusReactiveJwtDecoder
            .withIssuerLocation(...)
            .webClient(...)
            .jwtValidator(...)
            .build();
}

But I was thwarted by the limitations of the JwkSetUriReactiveJwtDecoderBuilder not allowing me to specify a jwtValidator, so I had to resort to an ugly detour via a variable:

@Bean
ReactiveJwtDecoder jwtDecoder(/* ... */) {
    var jwtDecoder = NimbusReactiveJwtDecoder
            .withIssuerLocation(...)
            .webClient(...)
            .build();
    jwtDecoder.setJwtValidator(...);
    return jwtDecoder;
}

For a little while I was considering submitting a PR to add jwtValidator(...) to the builder, but soon realized that this class contains 4 such builders, and I'd have to duplicate the functionality between them all (and then double that for the non-reactive variant.)

An option, which I believe is becoming more and more common, is to enable developers to chain setters by returning this. If the setJwtValidator(...) method I used above returned the NimbusReactiveJwtDecoder instance, I could at the very least get a compromise going:

@Bean
ReactiveJwtDecoder jwtDecoder(/* ... */) {
    return NimbusReactiveJwtDecoder
            .withIssuerLocation(...)
            .webClient(...)
            .build()
            .setJwtValidator(...);
}

It should be backwards compatible, and as an added benefit, the validation that already exists within setJwtValidator(...) will be applied so we wouldn't have to duplicate that as well.

This is just one example, but it's a common theme perhaps especially in Spring Security.

Thanks for listening to my TED talk! 😄