[Classpathx-javamail] Re: Mail 1.0 tar ball problems

[Fernando Nasser]

Hi Chris,

We filed a bug with Sun and got a response back saying that we are 
wrong.  And as the answer came from the spec head itself and from the 
javadoc, against all the odds, we are non-compliant.

I did not see this javadoc text he mentions BTW -- where is it?
IMHO the spec is dead wrong and violates the RFC, but we have no power 
to change it and probably there would be backward compatibility problems.

Can you change it to accept userid's only, even when strict is true?
We need it in the soon to be 1.1.

Thanks,
Fernando

Chris Burdess wrote:
> Fernando Nasser wrote:
> > Problem #2:
> >
> > There is also other failure on the API :
> >
> > With sun reference implementation :
> > $ java -cp mail.jar:. mail.TestJavaMail
> > Test Passed.
> >
> > With gnu javamail :
> > $ java -cp gnu-mail.jar:. mail.TestJavaMail
> > javax.mail.internet.AddressException: Missing final @domain in string  
> > Florent
> >        at javax.mail.internet.InternetAddress.validate(Unknown Source)
> >        at javax.mail.internet.InternetAddress.<init>(Unknown Source)
> >        at javax.mail.internet.InternetAddress.<init>(Unknown Source)
> >        at mail.TestJavaMail.main(TestJavaMail.java:44)
> > Test Failed !
>
>
> The documentation clearly states that the InternetAddress(String)  
> constructor is equivalent to calling the InternetAddress(String,  
> boolean) constructor with the second parameter set true. However, if in  
> the given test program, the constructor is replaced with the boolean  
> version with the second parameter set true, it fails with Sun's  
> implementation. Therefore there is either a problem with the API  
> documentation or a bug in Sun's implementation.

"I did look at this and sanity check this with the spec lead and the 
javadocs.  The test is correct:

The javadocs for parse includes the following:

  In particular, even if strict is true, addresses composed of simple
  names (with no "@domain" part) are allowed."