On Tue, 2012-09-04 at 14:01 -0500, [email protected] 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
