I am not too keen to grow CryptoCipher to an abstract class (Java 8 or not) with additional methods that would not typically be implemented by implementing subclasses.
The API of CC is quite low level, yes, but then adding higher level helpers there won't really help as it will be quite a confusing API to use, mixed with the lower level methods which you then should NOT use. A higher level CryptoUtils (?) could be a better place, it could have helpers to de/encrypt a byte[], a String and a Path without requiring the multiple steps. On 16 Jun 2016 2:17 p.m., "sebb" <seb...@gmail.com> wrote: > 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 > >
