| The JavaMail API is a fairly high-level representation of the basic components of any email system. The components are represented by abstract classes in the javax.mail package. For instance, the abstract class javax.mail.Message represents an email message. It declares abstract methods to get and set various kinds of envelope information for the message, such as the sender and addressee, the date sent, and the subject of the message. The abstract class javax.mail.Folder represents a message container. It declares abstract methods to get messages from a folder, move messages between folders, and delete messages from a folder. These classes are all abstract because they don't make many assumptions about how the email is stored or transferred between machines. For instance, they do not assume that messages are sent using SMTP or that they're structured as specified in RFC 822. Concrete subclasses of these classes specialize the abstract classes to particular protocols and mail formats. If you want to work with standard Internet email, you might use javax.mail.MimeMessage instead of javax.mail.Message , javax.mail.InternetAddress instead of javax.mail.Address , and com.sun.mail.imap.IMAPStore instead of javax.mail.Store . If you were writing code for a Lotus Notes-based system, you'd use different concrete implementation classes but the same abstract base classes. The JavaMail API roughly follows the abstract factory design pattern. This pattern allows you to write your code based on the abstract superclasses without worrying too much about the lower-level details. The protocols and formats used and the associated concrete implementation classes are determined mostly by one line of code early in your program that names the protocol. Changing the protocol name goes 90% of the way to porting your program from one protocol (say, POP) to another (say, IMAP). Service providers implement particular protocols. A service provider is a group of concrete subclasses of the abstract JavaMail API classes that specialize the general API to a particular protocol and mail format. These subclasses are probably (though not necessarily ) organized into one package. Some of these (IMAP, SMTP) are provided by Sun with its reference implementation in the undocumented com.sun.mail package. Others (NNTP, MH) are available from third parties. And some (POP) are available from both Sun and third parties. The purpose of the abstract JavaMail API is to shield you from low-level details like this. You don't write code to access an IMAP server or a POP server. You write your programs to speak to the JavaMail API. Then, the JavaMail API uses the service provider to speak to the server using its native protocol. This is middleware for email. All you need to do to add a new protocol is install the service provider's JAR file. Simple, carefully designed programs that use only the core features of the JavaMail API may be able to use the new provider without even being recompiled. Of course, programs that make use of special features of individual protocols may need to be rewritten. Since mail arrives from the network at unpredictable times, the JavaMail API relies on an event-based callback mechanism to handle incoming mail. This is exactly the same pattern (even using some of the same classes) found in the AWT and JavaBeans. The javax.mail.event package defines about half a dozen different kinds of mail events, as well as the associated listener interfaces and adapter classes for these events. While many people still fondly recall the early days of ASCII email and even ASCII pictures, modern email messages contain a bewildering array of multilingual text and multimedia data encoded in formats such as Base64, quoted-printable, BinHex, and uuencode. To handle this, the JavaMail API uses the JavaBeans Activation Framework (JAF) to describe and display this content. This chapter covers Version 1.3.1 of the JavaMail API, which is compatible with Java 1.1.8 and higher. The JavaMail API is a standard extension to Java, not part of the core JDK or JRE class library, even in Java 1.5. (It is a standard part of J2EE.) Consequently, you'll need to download it separately from Sun and install it on your system. It's freely available from http://java.sun.com/products/javamail. It comes as a Zip archive containing documentation, sample code, and the all-important mail.jar file. This file contains the actual .class files that implement the JavaMail API. To compile or run the examples in this chapter, you'll need to add this file to your class path, either by adding its path to the CLASSPATH environment variable or by placing mail.jar in your jre/lib/ext directory. The JavaBeans Activation Framework is also a standard extension to Java, not part of the core API. You can download it from http://java.sun.com/products/javabeans/jaf/. This download contains the activation.jar archive, which you'll also need to place in your class path. Finally, you may want to add some additional providers. Sun's implementation includes POP3, SMTP, and IMAP providers. However, third parties have written providers for other protocols such as Hotmail, NNTP, Exchange, and more. Table 19-1 lists some of these. Table 19-1. Mail providers | Product (company) | URL | Protocols | License | | JavaMail (Sun) | http://java.sun.com/products/javamail/ | SMTP, IMAP, POP3 | Free | | JavaMail/Exchange Service Provider (JESP): (Intrinsyc Software) | http://support.intrinsyc.com/jesp/ | Microsoft Exchange | Payware | | ICE MH JavaMail Provider (ICE Engineering, Inc.) | http://www.trustice.com/java/icemh | MH | Public domain | | POPpers (Y. Miyadate) | http://www2s.biglobe.ne.jp/~dat/java/project/poppers/index_en.html | POP3 | GPL | | JDAVMail (Luc Claes) | http://jdavmail. sourceforge .net | Hotmail | LGPL | | JHTTPMail (Laurent Michalkovic) | http://jhttpmail.sourceforge.net/ | Hotmail | LGPL | | GNU JavaMail | http://www.gnu.org/software/classpathx/javamail/ | POP3, NNTP, SMTP, IMAP, mbox, maildir | GPL with library exception |
|
