Why does Java class library still use String constants in place of enum

Question

I am using a few Java classes like javax.Mail.Session and MessageDigest for a tool I am building.

I noticed that it was difficult assigning them properties because they were using String constants for that.

For example, for a Session object, you have to assign String key value pairs in a Property instance which is then used to create a Session. So if you want your session to log debugging messages, assign "smtp.mail.debug", "true" in the Property instance. Similarly, if you want your MessageDigest to use SHA, create the MessageDigest instance as MessageDigest.getInstance("SHA")

I am yet to figure out what to do and where to get the information if say I wanted to implement MessageDigest using MD5 / RC4 etc, or add another property to my Session object.

Wouldn't it be really better if public enums were exposed by these respective classes to assign properties ?

Would save programmers lot of searching time at least.

Answer 1

I can see 2 main reasons:

Backward compatibility

The two examples you give were already part of the API before enums got introduced in Java 1.5. There's many more cases like that out there.

Extensibility

Take a look at for example MessageDigest. The javadoc specifies:

Every implementation of the Java platform is required to support the following standard MessageDigest algorithms:

• MD5
• SHA-1
• SHA-256

This lets other java.security.Provider libraries provide MessageDigest implementations for other algorithms than the ones minimally required by the API. Listing only the default ones in a restrictive enum on the API level would limit extensibility.

The same goes for allowing other javax.mail.Provider implementations to support additional/custom properties in the case of mail session properties.

Answer 2

This is likely due to the major focus of Java to provide backwards compatiablity to previous versions.

enum was introduced in Java 1.5, hence any API which was written against 1.4 or earlier will not provide support for this feature. This is very common amongst many of the APIs in the JDK

You also need to remember, enum is not extendable, meaning that if your wanted to introduce a new algorithm in the message digest, for example, you would be stuck...there'd be no way you could do it.

The same goes with the mail API, the mail API is provides support for distinctively different concepts, not all of them will have the same series of properties and would be impossible to devise a single enum capable of supporting ALL the various properties between different implementations that exist now or in the future, enum is just simply to inflexible for this job.

Answer 3

It will be to simple to think that reason is only backward compatibility.

For JavaMail because it has too many different settings related to different connectors and you only need some part of them to setup connection with one of supported protocols. Each connector is implemented in separate class and as I think, there is no reason to let for example, POP3 connector to know settings for IMAP connector.

For MessageDigest the reason is to support non-standard encryption algorithms, which is not packed with JDK but provided by 3rd party JCE adapters. For example how it will look for GOST algorithm provided by CryptoPro JCE:

  MessageDigest digest = MessageDigest.getInstance("GOST3411");