Since org.thymeleaf.Template is cached, I think it should implement Serializable.
I think making this should should be pretty easy - perhaps it could be done for Thymeleaf 3?
Besides implementing the interface in org.thymeleaf.Template, it would also have to be added to these classes:
Also, the fields:
should be removed and looked up on demand so that when those classes are serialized, the resourceResolver and processors aren't serialized too (since they don't change, and they're not serializable, they should not be serialized).
For folks that run into problems when using Ehcache ARC (Automatic Resource Allocation) due to this issue, I've written up how to work around it at http://candrews.integralblue.com/2015/07/issues-using-ehcache-with-arc-as-the-thymeleaf-cache/
I agree that once Templates are cacheable (in Thymeleaf 3.0 we would be talking about implementations of the org.thymeleaf.model.IModel interface) it would be desirable to make them implement java.io.Serializable.
Unfortunately, this is not possible with Thymeleaf 3.0's architecture and model implementations. For example (but not only), template engine events (implementations of org.thymeleaf.model.ITemplateEvent) contain references to template engine-wide structures such as the ITextRepository implementation they need to use to lazily initialize textual structures in memory when they are needed (and only then). Lazy initializations are almost everywhere in the new engine's model.
This kind of references cannot be easily converted into transient and re-initialized after deserialization because there might be more than one TemplateEngine instance in the same JVM, and everything in the engine's architecture is oriented towards supporting this kind of multi-engine, multi-configuration scenario. It's somehow similar to how Hibernate's still-not-hydrated dynamic proxies cannot retrieve a valid Hibernate session after a serialization + deserialization cycle: there is no way to know which session should be used (it might even live in a different server!).
So I'm closing this as declined, given I see no clear way of implementing this with the current or near-future engine architecture.