On Mon, 2012-09-03 at 09:39 +0200, Stefano Bagnara wrote: > At the moment the dom interfaces are also used to alter/create > messages using mime4j so they cannot be made immutable. >
I think this can also be done with the builder pattern by making builder accept an existing message or an InputStream content as an input. My concern here would be about efficiency. It would probably be unwise to end up with an implementation that causes a significant amount of intermediate copying just to have one extra field added or modified. > 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? > One must be mad to modify mime messages concurrently by multiple threads. Still, the idea of making DOM level interfaces immutable is worth pursuing, even at the price of API changes. +1 to the overall idea. Oleg > 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
