Jakarta Mail / Angus Mail
The standard MIME and mail-protocol API. It gives you the parts; your code decides how to assemble, configure, and reuse them.
CompareCompare approaches
Compare what each library handles,
and what it leaves to you.
Jakarta Mail, Spring Mail, Commons Email, and Simple Java Mail can all send a message. The real difference is what you still have to build, configure, secure, and maintain yourself.
At a glance
Four libraries, four different jobs
The difference is not only how high-level the API is. It is also which email problems the library already solves.
Spring Mail
Spring's JavaMailSender, MailException, and MimeMessageHelper. It fits naturally when the rest of the application already uses those APIs.
Apache Commons Email
A handful of message classes that save some Jakarta Mail boilerplate. Useful for basic messages, but most of the harder work is still yours.
CompareSimple Java Mail
Builds well-formed MIME and adds reusable message rules, DKIM, S/MIME, diagnostics, conversion, authenticated SOCKS, and batched, pooled, or clustered delivery.
Why Simple Java MailSide by side
What does each option handle for you?
High-level supportHelper / integrationYour code handles it
| What needs handling | Jakarta Mail / Angus ↗ | Spring Mail ↗ | Commons Email ↗ | Simple Java Mail ↗ |
|---|---|---|---|---|
| Message composition and MIME structure | Direct MimeMessage / multipart API | MimeMessageHelper | SimpleEmail, HtmlEmail, and MultiPartEmail | Fluent Email builder and automatic MIME structure |
| Attachments, embedded content, calendars | You compose the body parts | Helper for common MIME parts | Common attachments and HTML | Built-in attachments, inline content, pre-encoding, iCalendar |
| Recipient rules and validation | You build this | You add it around the sender/helper | Basic recipient setters | Builders, parsing, validation, defaults, forced overrides |
| DKIM signing | You add an extension or integration | You add an integration | You add an integration | Optional module; per-message or mailer default |
| S/MIME signing and encryption | You add an extension or integration | You add an integration | You add an integration | Optional module; send, read, decrypt, per-recipient certificates |
| Transport security and OAuth2 | Session properties and authenticators | Spring configuration plus Jakarta properties | Host, credentials, and TLS/SSL switches; no OAuth2 in a released version | Named transport strategies, OAuth2, verification, raw-property escape hatch |
| Async results and connection tests | You build this | You or your framework builds this | You build this | Async Future plus sync and async connection tests |
| Connection reuse and bounded batches | You open, reuse, and close the transport | You build this | You build this | Send a batch or run work against one open connection |
| Pooled and multi-cluster delivery | You build the pool and routing | You build the pool and routing | You build the pool and routing | Pool connections and route through keyed SMTP clusters |
| Authenticated SOCKS | You add the network integration | You add the network integration | You add the network integration | Optional authenticated SOCKS module |
| EML, MimeMessage, and Outlook conversion | MimeMessage is the object you work with | Direct access to MimeMessage | You add conversion support | Read and write EML, convert MimeMessage, optional Outlook MSG |
| Code and external configuration | Java and Session properties | spring.mail.* and Java configuration | Java setters; your application loads the settings | Builders, property files, environment variables, and profile overrides |
| Spring application integration | You wire the Session and transport into Spring | JavaMailSender, Boot auto-configuration, JNDI Session, MailException | You configure and inject the library yourself | Optional Spring module, injectable Mailer, simplejavamail.* binding |
| Diagnostics and settings inspection | Protocol debug stream and direct objects | Spring logging plus Jakarta tools | Exceptions and Jakarta Mail debug output | Connection tests, readable settings, routed debug output, validation, receipts |
| Low-level escape hatch | The API itself | Direct Jakarta objects and properties | Access to the mail Session and generated MimeMessage | Custom Session, properties, MimeMessage, and send operation |
“Your code handles it” does not mean the feature is impossible. It means you build it yourself or add another integration. If a cell is inaccurate, please report it.
Dependency footprint
What gets added to the application?
Foundation
Jakarta Mail / Angus
- Jakarta Mail API
- Angus implementation
You get the mail API and its implementation. Validation, how messages are built, connection reuse, and everything else live in your code or other libraries.
Existing framework
Spring Mail
- Jakarta Mail / Angus
- Spring Mail
If your application already uses Spring, Spring Mail adds only its mail integration. Otherwise, you bring Spring Framework dependencies into the application just to use it.
Small wrapper
Commons Email
- Jakarta Mail / Angus
- Commons Email
Commons Email is small because it does less. It adds message classes on top of Jakarta Mail; your application still handles most security and delivery work.
Modular library
Simple Java Mail
- Jakarta Mail / Angus
- Simple Java Mail
- Optional modules
Core covers well-formed MIME, reusable message rules, TLS and OAuth2, diagnostics, conversion, and simple batches. Add DKIM, S/MIME, pools and clusters, Outlook, Spring, authenticated SOCKS, CLI, or Karaf only when needed.
Choosing a layer
Where each option fits
FoundationJakarta Mail / Angus
You want to own the mail mechanics
Use Jakarta Mail directly when you want to build the Session, MIME tree, and transport handling yourself. You also decide how your application validates, secures, and reuses them.
Spring contractSpring Mail
Your application already speaks JavaMailSender
Simple Java Mail integrates directly with Spring. Stay with Spring Mail when existing code expects JavaMailSender and MimeMessageHelper already does enough. Spring Boot can configure the sender through spring.mail.* or a JNDI Session.
Convenience layerCommons Email
You only want a little less Jakarta Mail boilerplate
Commons Email makes basic Jakarta Mail code shorter, but that is about as far as it goes: version 2 mainly split the project into separate Jakarta and Javax artifacts, while the way messages are built and sent remained largely unchanged. The project still receives updates, but most recent work focuses on dependency, build, and security upkeep, which, combined with that limited scope, makes it difficult to recommend as the mail layer for a new application.
Complete SMTP solutionSimple Java Mail
You need more than message composition
Simple Java Mail handles well-formed MIME, reusable message rules, diagnostics, and conversion, then adds features outside Jakarta Mail itself: DKIM, S/MIME, authenticated SOCKS, connection pools, and SMTP clusters. Start with core and add only the modules you need.
Scope matters
Simple Java Mail focuses on outbound application email.
Jakarta Mail also covers IMAP and POP3, so use it directly for mailbox access. Simple Java Mail builds on it to compose, secure, and send outbound messages.