On 19 June 2016 at 01:18, Stian Soiland-Reyes <st...@apache.org> wrote: > 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.
No, it would be an additional method intended for use alongside the others. c.f. Writer which as: void write(String) and void write(String,int,int) > 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. To take the Writer case, it would be confusing to have to use Writer.write(String,int,int) and WriterUtils.write(String). > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
