The java.util.Base64 Encoder and Decoder classes have methods that accept strings as well as return strings. These can be used directly instead of converting between bytes and strings in the Spring classes.
This might also create a tiny performance improvement due to the java.util use of a deprecated, but useful String constructor, as well as its use of ISO_8859_1 encoding when converting strings to bytes. Given the allowable character range, ISO_8859_1 will result in the same conversions.
It appears that Base64Utils is only used within Spring Framework in GsonBuilderUtils, so a possibility would be to have that class use java.util.Base64 directly, and deprecateBase64Utils.
A final observation - Base64Utils has explicit checks for empty strings and byte array parameters. The outputs are the same without , just potentially doing a bit more work before reaching the same answer. if these checks were intended as a safety-check as opposed to a performance optimization, these checks could also be removed.
Comment From: bclozel
I'm repurposing this issue to completely deprecate Base64Utils for future removal. It was originally designed to support both commons-codecs as well as the Java 8 API, if present. Since then, it's passing calls to Java's Base64 without additional checks or behavior.
We should remove all usage of this API within Spring Framework and mark it for future removal.