Web services test code generator
Klaus Berg has recently released a test-code generator for JUnit-based Web service clients. If you're developing Web services using Axis2 and XMLBeans this wizard could turn your JUnit test client coding into a powerful code generation process. It also has uses for those using GUI-based testing tools like soapUI.

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Standard Edition >

Introduction to the Java Mail API

Learn how easy it is to develop e-mail applications using the Java Mail API

By Tony Nemil and Anil Hemrajani, JavaWorld.com, 06/09/99

The design of the Java Mail API is a good example of Sun's continuing efforts to provide common API frameworks for the Java development community. Emphasizing these common frameworks, as opposed to vendor-specific solutions, bodes well for the creation of an increasingly open development environment.

On the e-mail messaging front, higher level (consumer) developers can shop around for the implementation of the common API framework that best fits their needs -- or even support multiple implementations simultaneously. Lower level implementation providers can develop solutions that ensure efficient access to their mail server products. As an example of what this means, a small startup company can concentrate on developing that killer mail client and be assured of easily supporting it for any mail system environment. And the bluechip IT giant can focus on providing widespread access to its newly developed industrial-strength mail services, assured of a rich wealth of application support. The big winners are the IS customers, who can mix and match the best vendor products or solutions to develop their systems yet still swap components as requirements dictate (whether these be performance, financial, or political).

One key to developing highly reusable and open API frameworks is to emphasize abstract interfaces in a way that supports existing standards but does not limit future enhancements or alternative implementations. The Java Mail API does just that! Furthermore, Sun is also rapidly developing -- or providing through third parties -- default implementations and utilities for the most commonly available protocols and standards. For example, default implementations such as POP3, SMTP, and IMAP protocol servers are currently available, so you can start developing that award-winning killer app now without having to reinvent the protocol wheel unless you want to (or really need to).

A close-up look at the Java Mail API

The layout of packages and classes in the Java Mail API demonstrates one of the primary goals of its designers -- that the level of effort required by the developer to build an application should be dictated by the complexity of the application and the level of control required by the developer for the application. In other words, keep the API as simple as possible. The example application included in this article and the examples that ship with the Java Mail API amply demonstrate this point. (For a brief look at Java Mail terminology, turn to our Java Mail Glossary.)

On first glance, the number of Java Mail API classes and the detailed layout of these classes may cause you to believe you're in for a heavy learning curve. But in reality, once you get working, you'll find that this API is a simple and handy tool for implementing robust mail/messaging functionality in your applications.

Analysis of the primary Java Mail API package classes provides insight into the common mechanics of e-mail messaging systems. A high-level overview of the classes in the relative order in which they are normally encountered in a typical application reveals the simplicity of the Java Mail API.

Resources