james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Robert_E_...@Dell.com>
Subject RE: [DISCUSSION] make most of mime4j immutable
Date Tue, 04 Sep 2012 19:01:36 GMT
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

-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org] 
Sent: Tuesday, September 04, 2012 4:47 AM
To: mime4j-dev@james.apache.org
Subject: Re: [DISCUSSION] make most of mime4j immutable

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
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.


> 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 <stan.ieugen@gmail.com>:
> > 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

View raw message