We used to pass in a don't use newline flag when we used the apache commons codec base 64 encoder. There is not such a flag in the sun.misc encoder. If you override the bytesPerLine method to return Int.MaxInt, it will give you a heap overflow. So we just explicitly strip them.
strip \n from Base64StringEncoder to match the old behavior
can we add a test to make sure that the decoder doesn't care about newlines one way or the other?
add a test to make sure we can still decode the value with stripped n…
Added a test.
birdcage/util is now the canonical home of util code changes, the change should be made there...
birdcage is an internal repo.
i'll just merge it here.
This change was zapped when the code was moved to util-codec, but the correct change would have been to override BASE64Encoder.encodeLineSuffix and not emit the newline. This change, to replace \n instead of util.Properties.lineSeparator, breaks on Windows (where some of us are dual-booted); or at least the test breaks, since the decoder ignores [\r\n]*. But this behavior is arguably wrong, in so far as CR-LF is called for, and is supplied by Commons Codec which is used now: