Standard Names without Named Constants [closed]

Question

Is there a rationale behind the decision Sun made in making the Standard Names for cryptographic algorithms instead of named constants?

It seems Sun (well, now Oracle) puts forth an explicit effort in documenting algorithm names, but does not provide strongly defined named constants within the libraries. I understand that, from a cross-platform perspective, the string-search approach is advantageous.

However, in doing so means programmatic errors are delayed to run-time, which I can only see making things more difficult than necessary. Why is this?

Answer 1

I would guess that this will allow you to come up with your own non-standard names and factory implementations. (Or allow future plug-ins that use names that don't exist yet) without causing compilation errors.

This would also allow users to add new crypto classes at runtime by adding classes to the classpath that weren't known at compile time.

Answer 2

The String used in e.g. Cipher.getInstance(String algorithm) does not contain a single name, it contains the transformations as well. You would have something like "DES/CFB8/NoPadding" which indicates the DES algorithm, in Cipher Feedback mode with 8 bits output requiring no padding. This combination can be used other ciphers as well. So this would already produce a number of constants equaling cipher * modes * bitsizes * paddingmodes. Now you could create separate enumerations, but you can already see where it would start to hurt.

Strings are much more flexible than enums or (don't even go there) constants. This makes it very easy to add additional algorithms. You can even add algorithms and configure them in older software; just add a provider that implements the given algorithm. This is very important when used in a dynamic framework build up from providers and services.

As Luiggi indicated, it would be pretty easy to create a factory that takes an enum and returns a Cipher or Signature instance. You would only have to test the factory once.