Allow "optional-padding" for `Base64Variant`See original GitHub issue
(note: follow-up from https://github.com/FasterXML/jackson-databind/issues/2183)
Base64Variant instances either require use of specific padding character (and use it for output) or disable use of padding completely (neither written nor accepted).
But it seems that sometimes a more lenient variant would make sense: one that
- Does write padding (with specific character) and
- Accepts specific padding but does not require it (i.e. ok to omit)
It seems best to add a “mutant factory” method in
Base64Variant instance (something like
withLenientPadding(boolean) maybe?). Whether additional entries should be added
Base64Variants is an open question.
We’ll have to figure out what to do wrt existing “usePadding()” compared to new option; API may be cumbersome if we have 2 booleans but just 3 legal combinations.
Note that we may also change API for configuration for Jackson 3.x, later on.
- Created 5 years ago
- Comments:11 (11 by maintainers)
Top GitHub Comments
I would think chaining would usually be used like
Base64Variant base64Variant = Base64Variants.MIME.withPaddingForbidden();
I specifically do not want to make
Base64Variants mutable as they are immutable as that just opens up many new ways to get things to fail in interesting ways. 😃
@pavan-kalyan Addition of new constructors would be needed yes, and expected. Existing constructors should be left for compatibility reasons, although may be deprecated if that makes sense (for eventual removal from 3.0).
I do not remember exact details of current set up but I think it is rigidly keeping settings so that if padding is used on writing, it must be found on reading too.