geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: [JavaMail] Re: Geronimo standard Sun-API jars
Date Sat, 09 Aug 2003 08:47:34 GMT
On Friday, Aug 8, 2003, at 23:18 Europe/London, Danny Angus wrote:

> Alex,
>>> The problem is that there is a lot of code related to Mime parsing 
>>> and
>>> Address validation needed to conform to the RFC's in javaMail, there
>>> are a
>>> lot of mail RFC's ( and they 
>>> would
>>> require a lot of work to re-implement.
>> They aren't a requirement of JavaMail; they are a requirement of
>> SMTP/MIME and related RFCs. It just so happens that JavaMail also uses
>> them.
> I hope you're not seriously suggesting that it would be possible, 
> never mind
> whether or not it is a good idea, to create a mail application which 
> doesn't
> conform to the relevant RFC's.

No, the original mail message suggested that there were a lot of RFCs 
implemented in JavaMail and seemed to suggest that they were specific 
to JavaMail. I failed to say concisely that the RFCs were not just 
JavaMail, they were generic mail RFCs that should be in other 
implementations whatever flavour of mail API it was.

> If my criteria for cloning javaMail is that that action must offer 
> some real
> benefit, it would be seriously negated by failure to conform to the 
> relevant
> RFC's. Part of the value of javaMail is the extensive work done in 
> support
> of conformance.

Part of the JavaMail implementation conforms to the RFCs, yes, but that 
doesn't specifically negate having other implementations that also 
conform to the RFCs.

> ... is are the abstract and concrete classes in the
> javax.mail.* packages, these are part of Suns API and it is not 
> strictly
> required that an implementation re-create them. In fact the original 
> reason
> mooted for doing so was simply to make them available under the ASFL. 
> This
> is perhaps a worthwhile sentiment as far as the j2ee API's which are 
> mainly
> interfaces are concerned, but javax.mail is mainly implementation, and
> implementation of a lot of unattractive RFC conformance to boot.

The APIs don't, in themselves, provide the conformance. The 
implementation (com.sun...) packages provide the conformance/validation.

In any case, the API for JavaMail tends to be bogged down with 
low-level representations (such as MimeBodyPart) when it could present 
a more unified interface such as getAttachment(). IMHO the JavaMail 
provides a low-level representation, which is less useful for 
developers wanting to send/receive mail.

>>> I'd be very wary about starting down the road of an Apache clone of
>>> javaMail
>>> unless it really offers serious advantages.
>> o Easier API to use to generate/send mails
>> o Less global configuration settings (JavaMail uses global system
>> properties)
>> o Conformant JavaBeans representation of MimeMessage
>> o Use of Mail.getAttachment() to facilitate attachments, rather than
>> presenting the low-level layer of how they are transmitted in MIME
>> Multipart formats
> I don't believe that cloning javaMail would give anyone much 
> opportunity to
> add functionality to the API, we're simply talking about cloning it not
> extending it.

I was talking about an extended Mail API set, that provided a JavaMail 
API to allow legacy systems to use it as well. Having had problems with 
JavaMail (as above) I wanted to try and create an implementation to 
address some of those issues.

> Any ASF clone of javax.mail would have to be a direct replacement for 
> the
> original, if you want to implement extended functionality in order to 
> better
> manage internal handling of the objects surely the normal use of 
> inheritance
> and polymorphism is sufficient?

In the case of polymorphism, not really. Part of the problems with 
JavaMail are the non-trivial use of mail attachments, and the fact that 
they are also non-JavaBean compliant means that you can't easily use 
JavaBean systems with Mail messages. [I wrote a JavaMail-based Web 
client last week, and discovered that using JSTL I could say 
${message.subject} but not ${message.content} because the MimeMessage 
doesn't conform to the JavaBean spec, despite there being a 
message.getContent() method)

> It isn't possible for *us* to extend the specification either, we're 
> not
> Sun.

Nor was I suggesting that we should -- I was suggesting a replacement 
with a JavaMail API layer to provide backward compatibility.

> Well hold on until things settle down, it all seems a bit up in the 
> air here
> at the moment :-)

I'll take this discussion over to the JAMES team, and hopefully then 
ApacheJ2EE and JAMES will move in the right direction.


View raw message