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: MessageBuilder refactoring; was Re: dom / message refactoring
Date Tue, 25 Jan 2011 23:12:48 GMT

> The fact is that probably ServiceLoader was required in the previous
> design, using Abstract classes. That design is the only I'm aware of
> that would have allowed future releases to add more methods to each
> class without breaking compatibility with older sources. Now that you
> removed this possibility by switching everything to interfaces I
> understand that the ServiceLoader seems "horrid". Most stuff I did in
> the dom package has been done with this precise goal, so I can't
> "defend" that code if we remove the goal :-)  That said you also
> should understand that the ServiceLoader, like most SPI model out
> there, is simply an abstraction layer. You are free to directly
> instantiate the implementation.
> I didn't (and I currently don't) know a better way to create a forward
> compatible, yet extensible, API, but I'm far from being an expert API
> designer.


I am sorry I do not see how the service locator pattern can help with
maintaining forward compatibility between releases. I always thought
that it's goal was primarily to decouple layers and to enable multiple
implementations of a service interface.   


> >
> > How do you want me to proceed now?
> I'm happy to see you pushing. *Go* *ahead* :-)  I just explained why I
> did things in a given way and how I evaluate changes. This was not a
> comment to stop you, but just something to let you be more informed.
> As long as 0.7 will support the Monitor object, the fixed headless
> parsing and the fixed field folding I will be happy (I currently have
> 0.7-SNAPSHOT as dependency for this and not for the DOM abstraction).
> Stefano

I do not want to 'push' if there is no consensus that I am pushing in
the right direction.


View raw message