On Tue, 2012-09-04 at 14:01 -0500, Robert_E_Lee@Dell.com wrote:
> This is something I would like to see as well. One way to have you cake and eat it too would be to define implementations as mutable, but have them implement immutable interfaces:
> 
> public interface ImmutableMessage
> {
> 	// getters
> 	// other non-state-changing methods (clone(), equals(), hashcode(), et all; optional)
> }
> 
> public interface MutableMessage extends ImmutableMessage
> {
> 	// setters only (getters implied via inheritance)
> 	// any state-changing methods (?)
> }
> 
> public class MessageImpl implements MutableMessage
> {
> 	// getters and setters
> }
> 
> The MessageBuilder would return MutableMessage to the mime4j client, which can in turn pass this along to any downstream code in the application as a (threadsafe) ImmutableMessage, since MutableMessage extends ImmutableMessage. This would, of course, require that any properties returned from the getters in ImmutableMessage be either defensively copied, or mutable themselves, and today we have a getter that returns java.util.Date, which is mutable, and not defensively copied. On the other hand, since message implementations are mutable, message construction performance and "intuitiveness" shouldn't be affected -- this solution just provides an optional immutable "view" into the existing mutable data structures via a simple (safe) cast. Additionally, this solution doesn't have to be implemented in a way that breaks the existing API (although the API probably shouldn't expose java.util.Date, but that's a separate issue).
> 
> Another solution would be to define a completely separate immutable class heirarchy that "wraps" the existing mutable heirachy, but that is far less elegant. Applications can do this today with no effort on mime4j's part.
> 
> I think the cleanest overall option, is to simply change the API to be completely immutable, and rewrite all message creation code to work with an immutable API, but I think it's too late for that at this point, and possibly not a great idea to begin with.
> 
> Just my $0.02.
> 
> -Rob L
> 

Rob

mime4j is still at 0.x, so it is not expected to be API stable. I
personally think we can and should make API changes where appropriate.
Feel free to pursue the cleanest option. You might want to do it on a
separate branch or on github first, though.

Oleg