At the moment the dom interfaces are also used to alter/create messages using mime4j so they cannot be made immutable.
I don't see big advantages in making it thread safe as I don't see many use case where a single message is parsed into a dom and read by multiple threads concurrently: can you provide an use case? On the other side immutability could bring us some performance, but this doesn't require an API change: if this is the goal then we could provide an immutable dom implementation and let a specific builder to build the dom using immutable classes (that will throw exceptions if some setter is called). Stefano 2012/9/2 Ioan Eugen Stan <[email protected]>: > Hello, > > After looking around in mime4j I noticed that most of the API > interfaces from mime4j-dom provide getters and are mutable. This means > that implementations are also not thread safe. > > I propose we move to an Immutable API implementation with nice > builders. This will make things thread safe and make life easier for > our users. > > This will most likely mean a change in the API. > > I think this is worth it, as we may have less bugs in our > (multi-threaded) code. What do you think? > > Cheers, > > -- > Ioan Eugen Stan / CTO / http://axemblr.com
