Recipe 19.5 Providing Mail Settings

Problem

You want a way to automatically provide server host, protocol, user, and password.

Solution

Use a Properties object.

Discussion

You may remember from Recipe 7.7 that java.util.Properties is a list of name/value pairs, and that my FileProperties extends Properties to provide loading and saving. In several places in this chapter, I use a FileProperties object to preload a large variety of settings, instead of hardcoding them or having to type them all on the command line. When dealing with JavaMail, you must specify the mail hostname, username and password, protocol to use (IMAP, POP, or mailbox for reading), and so on. I store this information in a properties file, and most of the programs in this chapter will use it. Here is my default file, MailClient.properties :

# This file contains my default Mail properties. #  # Values for sending Mail.address=[e-mail] Mail.send.proto=smtp Mail.send.host=localhost Mail.send.debug=true # # Values for receiving Mail.receive.host=localhost Mail.receive.protocol=mbox Mail.receive.user=* Mail.receive.pass=* Mail.receive.root=/var/mail/ian

The last two, pass and root, can have certain predefined values. Since nobody concerned with security would store unencrypted passwords in a file on disk, I allow you to set pass=ASK (in uppercase), which causes some of my programs to prompt for a password. The JavaMail API allows use of root=INBOX to mean the default storage location for your mail.

The keys in this list of properties intentionally begin with a capital letter since the property names used by the JavaMail API begin with a lowercase letter. The names are rather long, so they, too, are coded. But it would be circular to encode them in a Properties object; instead, they are embedded in a Java interface called MailConstants , shown in Example 19-6.

Example 19-6. MailConstants.java

/** Simply a list of names for the Mail System to use.  * If you "implement" this interface, you don't have to prefix  * all the names with MailProps in your code.  */ public interface MailConstants {     public static final String PROPS_FILE_NAME = "MailClient.properties";     public static final String SEND_PROTO = "Mail.send.protocol";     public static final String SEND_USER  = "Mail.send.user";     public static final String SEND_PASS  = "Mail.send.password";     public static final String SEND_ROOT  = "Mail.send.root";     public static final String SEND_HOST  = "Mail.send.host";     public static final String SEND_DEBUG = "Mail.send.debug";     public static final String RECV_PROTO = "Mail.receive.protocol";     public static final String RECV_PORT  = "Mail.receive.port";     public static final String RECV_USER  = "Mail.receive.user";     public static final String RECV_PASS  = "Mail.receive.password";     public static final String RECV_ROOT  = "Mail.receive.root";     public static final String RECV_HOST  = "Mail.receive.host";     public static final String RECV_DEBUG = "Mail.receive.debug"; }

The fields in this interface can be referred to by their full names; e.g., MailConstants.RECV_PROTO. However, that is almost as much typing as the original long string (Mail.receive.protocol).^[1] As a shortcut, programs that use more than a few of the fields will claim to implement the interface, and then can refer to the fields as part of their class; e.g., RECV_PROTO. This is a bit of a trick on the compiler: the interface has no methods so anybody can implement it, but in so doing "inherit" all the fields (remember that fields in an interface can only be final, not nonfinal).

^[1] A bit like typing BorderLayout.NORTH instead of just North.