james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject RE: [DISCUSSION] make most of mime4j immutable
Date Tue, 04 Sep 2012 21:40:40 GMT
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


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.


View raw message