commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject [CRYPTO] Possible new method for CryptoCipher interface; API evolution
Date Thu, 16 Jun 2016 13:17:01 GMT
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message