IMHO none of the above. This is too far out in the weeds. I don't want to maintain the extra complexity for every possible combinatorial combination.
On Fri, Oct 23, 2026 at 1:33 PM Gary Gregory <[email protected]> wrote: > > Let's see what the OP replies with in the ticket... otherwise it's just > busy work with no customer. > > Gary > > On Fri, Oct 23, 2026, 09:26 Adarsh Kumaromrey <[email protected]> > wrote: > > > Hi Gary, > > > > Thank you for the quick response, the Javadoc clarification and the > > XML whitespace workaround. The STRICT contract is much clearer now. > > > > Since you mentioned that a PR to improve the API would be welcome, I > > would like to check one idea with you before writing any code: > > > > An opt-in Base64.Builder option so that STRICT decoding ignores line > > separators and whitespace, while still validating the alphabet, > > padding and trailing bits. The default would stay exactly as in > > 1.23.x, so there would be no behavior change for existing callers. > > > > The goal is to avoid callers having to pre-process input themselves > > when they receive wrapped Base64 but still want trailing-bit > > validation. > > > > I have three questions: > > 1. Would an option like this be welcome at all, or would you prefer to > > keep the API surface as it is? > > 2. If yes, do you have a preferred shape or name for it? > > 3. Should it cover only Base64, or Base32 as well? > > > > If you agree, I will send a PR with tests and Javadoc. If not, I am > > happy to drop the idea. > > > > Thanks, > > Adarsh > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > -- Elliotte Rusty Harold [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
