geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Monson-Haefel <>
Subject Re: [JavaMail] concerns
Date Tue, 19 Aug 2003 05:00:13 GMT
The critique of Alex's contribution is certainly well intended, but its also
kind of odd. Why should the critic complain that there is not enough
planning and then go on to say that Alex's impl cannot be differentiated
from the Sun impl?  If it cannot be differentiated, then what prior planning
is necessary?

I've spoken to some people who have attempted to use JavaMail in a high
volume production environment and abandoned it because it was too slow ...
IMO, if Alex can improve on that, than more power to him.

I also believe that it behooves Geronimo to have its own implementation
because it gives us the option of going beyond the spec to impl

Anyway, the critique appears to have been offered in sincerity, but it
doesn't make much sense to me.


On 8/18/03 4:13 PM, in article, "Alex
Blewitt" <> wrote:

> On Mon, 18 Aug 2003, Danny Angus wrote:
>> As an observer, and having admited my interest in JavaMail in geronimo I'm
>> slightly concerned that there seems to be very little oversight or direction
>> involved with the JavaMail effort.
>> From where, though? I had volunteered to do it, and worked away at
> providing the implementation. From a community PoV, the files haven't been
> in there very long but no doubt others will pick it up where it needs to
> be handled.
>> Alex is obviously working hard, but I'm concerned that what he's doing may
>> not be, through no fault of his, the best decision for the project.
>> I have a couple of reasons for saying this, none of which reflect badly on
>> Alex, and I want to emphasise that this is not intended to be criticism of
>> him in any way.
> Not taken as such, don't worry :-) I have a fairly thick skin (along with
> a fairly thick body and a fairly thick skull)
>> 1/ JavaMail differs from most of the other j2ee API's in that it is 80%+
>> implementation and >20% interfaces, so an ASFL clone is far from trivial,
>> and represnets a serious investment by the project, one which will have to
>> be updated and maintained.
> It's true that there's a lot more to the API than just the interfaces
> (unlike EJBs, for example, which is just pure interfaces). This is why it
> took me a week to generate the 100 odd classes in the JavaMail API in the
> first place.
> However, one of the reasons it took me a long time to do in the
> first place is that I didn't /just/ do the APIs -- I also implemented
> (where possible) the methods that go with it. Gut feeling is that I've got
> between 60% and 80% of the base implementation of the JavaMail API done.
> (Key things missing are the MimeMessage and Folder methods, though some
> are done).
> As an example, the and javax.mail.event packages are
> 100% implemented (along with tests for the javax.mail.event package; I am
> developing a simple test-message and test-folder to write tests for the
> search package).
> For maintenance purposes, I am developing a set of JUnit tests which will
> hopefully avoid the need (or difficulty) of too much maintenance.
>> 2/ Without an active and enthusiastic community (c.f. a lone developer) to
>> support it it will never be a quality replacement for sun's packages, the
>> quantity of conformance with Sun's specs and with RFC's required to do the
>> job properly is significant and (IMO) large.
> To a greater extent (and certainly initially) this is true. But once the
> core bits are done, it will be easier to maintain. Some of the RFCs are
> implemented as Sun classes in 1.4 anyway (such as the URI class, which was
> helpfully pointed out to me :-) although some are still not yet
> implemented.
>> Given the above I haven't seen anything which indicates that re-writing
>> javaMail (compared to implementing those areas which are left as interfaces
>> with the specific intention of being implemented by 3rd parties) is a goal
>> of this project, or more importantly why it is considered to be a worthwhile
>> direction.
>> From a personal PoV, I've used JavaMail before and have had experience
> with using it. I thought it might be fun to work on as an initial task
> working with Geronimo. And it's better than writing up my thesis :-)
>> The fact is that this work will require considerable effort and, if it is
>> done correctly, only ever result in a product virtually indistinguishable
>> from Sun's original save for the licence.
> Yes, this is indeed the case. In fact, the only parts where we could
> differ would be in the implementation of the actual transport/stores
> anyway, since the API is firmly fixed in how its supposed to behave.
>> I'd like to know if this really is a goal of Geronimo or whether the
>> situation of javaMail could be given more attention before Alex expends too
>> much more effort on it.
> The J2EE 1.4 spec mandates a JavaMail implementation of some kind; whether
> this be based on the Sun RI or another open-source one is still open.
> (Additionally, queries have been given to the nature of (L)GPL code, which
> may rule out (L)GPL implementations of JavaMail)
> The goals I had when starting this were;
> o To provide JavaMail integration with Geronimo without dependency on
> Sun's JavaMail (Mainly for licensing reasons)
> o To provide an Apache implementation of the mail store/transport
> protocols
> o Subsequently to make the same version available as part of the
> jakarta-commons packages, for possible integration into other Apache
> products like JAMES
> I have heard that the ASF are in talks with Sun regarding licensing their
> JavaMail implementation through an open-source license. Should this come
> about, then clearly the work I will have done implementing the APIs will
> become obsolete and the correct decision will be to replace them with
> Sun's implementation. As yet, however, I don't know what stage this is at,
> so feel that it is worth gambling to make it available now and for the
> initial, if not subsequent, releases of Geronimo.
> It has also given me opportunity to work with ASF; something which I've
> not done before and it's been pretty enjoyable :-)
> And, as I've mentioned above, it's a lot more fun than writing up the
> thesis :-)
> Alex.
> /***************************************************************\
> |*       Alex Blewitt       * Hug, and the world hugs with you *|
> |*  *
> *|
> |* Mobile: +44 7966 158 647 *    Spread a little happiness     *|
> \***************************************************************/

View raw message