You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2016/06/16 13:17:01 UTC
[CRYPTO] Possible new method for CryptoCipher interface; API evolution
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
Re: [CRYPTO] Possible new method for CryptoCipher interface; API evolution
Posted by sebb <se...@gmail.com>.
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" <se...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [CRYPTO] Possible new method for CryptoCipher interface; API evolution
Posted by Stian Soiland-Reyes <st...@apache.org>.
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" <se...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>