Hashing in Java and Java Cryptography Architecture (JCA) design

[John Newman]

This seems to me overly complicated for a simple task of
instantiating a MessageDigest object:

MessageDigest md = null;
try {
    md = MessageDigest.getInstance("SHA-1");
} catch (NoSuchAlgorithmException nsae) {}

Couldn't MessageDigest simply be an *interface* and
the SHA funcionality a special *implementation*, like so:

MessageDigest md = new ShaMessageDigest();

?

But instead we have these factory methods (accross all of the JCA
core classes) which throw exceptions, polluting the code. Is the
Provider abstraction really needed? The only real benefit I see is
neater class names.

In fact - couldn't we get rid of the entire Java Cryptography Architecture (JCA)
as it is and redesign it to be more object oriented? For example, couldn't this:

byte [][] args = //...
MessageDigest md = //..
md.update(args[0])
md.update(args[1]);
md.digest();

become this:

byte [][] args = //...
MessageDigest md = //..
md.update(args[0]).update(args[1]).digest();

or maybe even this:

MessageDigest md = //..
byte [][] args = //...
new IntermediateDigest(
    md,
    args[0],
    args[1]
).bytes()

where IntermediateDigest itself could be an argument to MessageDigest's update()
method, making things like H(H(x), y) look much more compact and readable?


--Janez