Fork me on GitHub
Simple Java Mail
Simple API, Complex Emails

Migrating to Simple Java Mail 7.0.0


From JavaMail to Jakarta Mail

Impact: Your server may need to switch dependencies as well

JavaMail hasn't been maintained since 2018 and Jakarta Mail has picked up the torch as the official successor. More and more projects are updating to Jakarta Mail now, and it is time Simple Java Mail can be there in the trenches with them.

Generally this should not be an issue, but I already got an (invalid) bug report where a Geranimo server failed because dependencies are manually managed on the server side. So if you switch to 7.0.0, make sure your server does as well.


From Java 7 to Java 8

Impact: Your project won't work in Java7 JVM's anymore

For the longest time I held off upgrading to Java 8, because there was always a small user base of around 5-10% with Java7. However I think it's finally time to let go of trusty Java7 and switch to Java8 and benefit from language features such as lambda's and CompletableFuture.

If you are still on Java7, then congrats: you are a rare and special breed indeed. You must go on without me (a single teardrop falling).


A new Email Validation library

Impact: You need to replace mailer api calls for configuring validation criteria and if you have them, any direct calls to EmailAddressValidator.

Until 7.0.0, Simple Java Mail relied on email-rfc2822-validator for email address validation that was the most RFC compatible validator around. However, it became clear the aging project was not able to keep up with current needs. Being a regex based solution and with bug reports coming in that were difficult to reproduce, it was always a headache, and sometimes we just had to turn bug reporters away.

That is, until we got a bug reporter that claimed to have the first lexer based email address validation library that was not only easier to debug and documented better, it was correcter, up-to-date with recent RFC's and much, much faster. The switch then was an easy descision. and luckily the migration is relatively simple.

Fixing compile issues regarding this is straightforward, and I will just point to the updated feature section for address validation.


Async responses are now CompletableFutures

Impact: Any handlers you registered on AsyncResponse need to replaced with CompletableFuture versions

With the release of 7.0.0 your async result handlers will not compile anymore because AsyncResponse (and contained Java7 Future) is gone. Instead, the much more robust Java8 CompletableFuture is in place now.

I've updated the feature section on async response handling with examples and links to tutorials, so you should be able to easily migrate your handlers.