Enhancement: make Email serializable

[ashokgelal]

Hi,
I need to serialize Email objects to be able to sent them later (processed by a different server using ActiveMQ). But since none of the classes implement java.io.Serializable interface, I'm not able to use auto serialization (unless I manually serialize/deserialize them, which, of course, is a lot of work).

I'm wondering if you have thought about having some of the classes (like Email, Recipient etc) implement the marker Serializable interface or not. If you have, is there any downside of implementing the interface that I'm missing? If you haven't thought of it, would you be open to having those classes implement the interface?

Thank you!

[bbottema]

Hi @ashokgelal, I would be open to that, depending on the impact on the code. But frankly speaking, I assumed Java serialization is a thing of the past and I'm not convinced yet it is still widely used. Therefor I'm a little reluctant to include this in the library.

[ashokgelal]

I've done some research, but since it is just a marker interface and comes with no method of its own, there seems to be no side-effects of any kind. It really doesn't force users to do anything different but only makes it available if they want to use it.

... I assumed Java serialization is a thing of the past and I'm not convinced yet it is still widely used. Therefor I'm a little reluctant to include this in the library.

I understand your reluctance, and not that I'm a proponent of Java serialization either, but since serialization is at the core of Java, there are systems there that depend on this serialization mechanism (like ActiveMQ I'm using). Also, this library already uses classes from javax.mail package that implement Serializable (such as RecipientType class) and the "serialization flow" kind of abruptly stopping at this library defeats the purpose of having these core classes as serializables.

Anyway, I think the cost of making some of the classes of this library serializables is very low and would make it even more compatible with Java ecosystem making it open for even wider adoption. I hope you'll consider it seriously.

[bbottema]

there are systems there that depend on this serialization mechanism (like ActiveMQ I'm using)

Except that ActiveMQ doesn't depend on it, but merely supports it. Serializing email objects for transport is not interoperable, human readable and is not language agnostic, hence it not being used much anymore in general except for legacy systems. Normally you would put the JSON/XML/GSON whatever on the queue and create the email based on that in whatever language is receiving the data.

That being said, if it is just about adding a marker interface, I might not have much issue with that, but I seem to remember from school something about needing custom serialization (perhaps for nested objects that don't implement the interface).

It's been awhile, I have not dealt with serialise at any corporate company I worked for in the last 14 years.

[ashokgelal]

Oops! I meant "supports by default" without having to do anything else.

Normally you would put the JSON/XML/GSON whatever on the queue and create the email based on that in whatever language is receiving the data.

That's exactly how I'm doing it right now. The reason I asked for this feature was because I was surprised to not being able to serialize an Email object as I was rapid prototyping something.

[bbottema]

Ok, you convinced me, as long as we don't have to implement manual serialization logic. If you feel up to it, I'll accept a PR on master. Else I will pick it up in some time.

[bbottema]

I can't guarantee serializibility, as I don't have control of the datasources used as attachments and embedded images... so that's a problem, unless I manually serialize/deserialize that, rather an involved job...

[bbottema]

Will release 5.4.0 soon with this feature (make sure you use compatible serializable datasources). OSS Sonatype is having networking issues now though, so I can release to Maven Central for the moment.

[ashokgelal]

Thanks!

[bbottema]

Released in 5.4.0. Note some fields have been made transient: data sources (attachments, embedded images), mime messages (forwarded email)

[metametadata]

We create AttachmentResources using jakarta.mail.util.ByteArrayDataSource and apparently such data sources are lost on serialization. Error on trying to send the deserialized email with attachments:

java.lang.NullPointerException: Cannot invoke "jakarta.activation.DataSource.getName()" because the return value of "org.simplejavamail.api.email.AttachmentResource.getDataSource()" is null

What could be a solution to this issue? Are there any ready-to-use serializable data source classes available somewhere?

Thank you.