Java Enterprise Best Practices

Manage Attachments in Memory

File attachments can be a real drain on system performance. They can be arbitrarily big, and most methods for handling them involve writing them out to disk. This requires access to a directory on the server and can impose all sorts of performance penalties.

JavaMail, oddly, doesn’t support nontext MIME parts based on objects in memory. JAF DataHandler objects can be retrieved only from a file or URL. This means that even if you’ve generated the attachment in memory, you still have to write it out to disk and then attach the ondisk file to your email. The exception, as you’ve seen, is when you already have a DataHandler object, such as when you receive an incoming SOAP message via JAXM.

Example 10-7 shows how to get around this limitation by subclassing the MimeBodyPart object. The standard MimeBodyPart implementation includes a protected field, contents, that contains the raw content of the MIME part. The JavaMail API also includes a utility class, MimeUtility , that can encode content streams in a variety of ways, including with the base64 and the older UUEncode standards. You can use these two features to create your own MIME encoding system, bypassing JAF altogether.

The StreamBasedMimeBodyPart class has a constructor that accepts an InputStream, a content type, and a filename. The filename is associated with the file attachment so that the recipient can open it easily. Because this is a simple example, the constructor contains all the logic, ...