reusing jakarta.mail.Transport for multiple without using batch-module

[rw7]

I'd like to reuse a SMTP connection (and therefore jakarta.mail.Transport) for sending more that one email. I'd like to have some API that can be used like this:

try(MailerTransport transport = mailer.openTransport())
{
	for(int i = 0; i<5; i++)
	{
		transport.sendMail(EmailBuilder.startingBlank().
				...
				withSubject("mail " + i + "/5"));
	}
}

I can't use batch-module, as it wants to maintain threads and the message queue for me. I have just one thread fetching emails from the database and sending it to smtp blockingly. No need for parallel threads or connections pools. Just one thread reusing the transport for more than one email.

I made this possible with hacking simple-java-mail, but it says: "Providing access to Session instance for emergency fall-back scenario. Please let us know why you need it." So here I am.

Best regards,
Ralf.

[bbottema]

Thank you for reporting your use case even if you hacked it already (and it's been a year 😅). I'm going to look into this, sounds like a useful addition.

[bbottema]

Implementation prepared as a small Java API expansion that keeps Jakarta Mail Transport hidden:

mailer.sendMailsInSimpleBatch(emails);        // uses the mailer's configured async default
mailer.sendMailsInSimpleBatch(emails, false); // block this Mailer API call until the simple batch is done
mailer.sendMailsInSimpleBatch(emails, true);  // return immediately; the whole simple batch runs as one scheduled task

Important distinction: the simple batch itself is never concurrent or pooled. The async flag only controls the immediate Mailer API call. Whether async is true or false, the emails are still sent sequentially, one by one, over one SMTP connection. So async = true does not mean queued sending, parallel sending, connection pooling, retry-oriented flow control, cluster coordination, or batch-module behavior. It only means Simple Java Mail schedules the whole sequential operation on the configured executor and returns a CompletableFuture immediately.

This is intentionally positioned as a simple fallback for caller-managed loops where the caller already owns the queue/source and only wants to avoid reconnecting per email. For queued sending, connection pooling, concurrency, cluster coordination, retry-oriented flow control, or high-throughput use cases, the batch-module remains the primary API.