I have been looking at creating examples for Crypto. It occurred to me that a common use case is encryption/decryption of small chunks of data that can readily be stored in a local byte array.
For such cases, there is no need to use both update() and doFinal(). Having to provide the input array offset/length and the output array offset is tedious. It might therefore be useful to provide a method with the signature: int doFinal(byte[] input, byte[] output) This got me thinking about how the code should be designed to enable evolution of the API in future releases. A method added to an interface breaks compatibility unless one uses Java 8 with its default implementation feature. Whereas if the CryptoCipher interface were turned into an abstract class, changes could be readily implemented without breaking the API. I'm inclined to think that using an abstract base class is better than an interface. - it's easy to extend and to provide helper methods - it works with Java 7 (does not require Java 8) - AFAICT an implementation *is* a CryptoCipher The same applies to the CryptoRandom. I wonder also whether the stream.input.Input and stream.output.Output interfaces should be abstract classes instead. They seem to mirror the java.io.InputStream/OutputStream abstract classes. So maybe they should be dropped in favour of an abstract subclass of InputStream/OutputStream? --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
