[JavaMail] re-engineering of JavaMail from specs?

[Alex Blewitt <Al...@ioshq.com>]

I have a question regarding reverse engineering JavaMail: what can I 
base the reverse engineering on? There are two places I can use to 
generate this information:

o The JavaMail specification PDF document
o The JavaMail API docs

My preference would have been to use the former, but there are a lot of 
things that aren't exposed in the PDF document. For example, the API 
docs have a class:

public class MessagingException {
	public MessagingException(); // and other constructors
	public Exception getNextException();  // get the chained exception
	public void setNextException(Exception e); // change the chained 
excception
}

However, the PDF spec doesn't contain any indication of the APIs, and 
just infers that there is a class called MessagingException.

So, in order to meet the specs, which should I follow? Should I provide 
all public  methods listed in the API documentation, or just those that 
are directly mentioned in the PDF? My fear is that if I do the latter, 
then we'll end up failing the TCK since it won't have all the methods 
the TCK is expecting.

Alex.

Re: [JavaMail] re-engineering of JavaMail from specs?

[Mark Mahieu <ma...@twistedbanana.demon.co.uk>]

Alex Blewitt wrote:

> Yes, but the question I have is whether I can legally read Sun's API 
> and then write an implementation of it. I'm not going to touch the 
> source code, but there isn't any way of creating a JavaMail 
> implementation using the PDF Spec alone; it simply doesn't provide 
> enough code.

Yeah the JavaMail spec seems a bit lacking in that department; maybe 
they figured that a royalty-free license to use the RI would preclude 
anyone wanting to reimplement it ;-)

> This is my problem; how can I implement the JavaMail API in a way that 
> is legally acceptable by the ASF? Is taking the signatures from the 
> API documentation legally the right way to go? Otherwise I don't see 
> how this would be possible.

Well the maintenance revision for the JavaMail 1.3 API used JCP version 
2.1 (*and* it's part of J2EE of course) so it seems logical that the 
public signatures of anything under javax.mail would be fair game.  
Though I suppose you'd still need clarification from Sun given the lack 
of API details in the spec.

> Alex.

Mark

Re: [JavaMail] re-engineering of JavaMail from specs?

[Alex Blewitt <Al...@ioshq.com>]

On Tuesday, Aug 12, 2003, at 23:04 Europe/London, Danny Angus wrote:

> Alex,
>
> (BTW are you in Europe?)

Yes, in glorious Milton Keynes. Home of the concrete cows. No, I don't 
know why either ... 
http://www.askmk.com/placesofinterest/concretecows.html

>> Yes, but the question I have is whether I can legally read Sun's API
>> and then write an implementation of it. I'm not going to touch the
>> source code, but there isn't any way of creating a JavaMail
>> implementation using the PDF Spec alone; it simply doesn't provide
>> enough code.
>
> Well if others have typed in interfaces from the javadocs and not been 
> "gone
> after" I'd suggest that reading the javadocs is OK.
> In addition it would be pretty much 100% impossible otherwise.
> Read the licence and pay attention to the no reverse engineering bits..
> At the end of the day if you're really worried someone can ask the 
> Board to
> get legal opinion.

The license for the JavaMail spec is at 
http://java.sun.com/products/javamail/JavaMail-1_2-spec-license.html
(although this is for the 1.2 spec, presumably the same applies to the 
1.3 license)

It seems to suggest that the spec is available for clean-room 
reimplementations of the API, provided that you implement the classes 
required by the spec, that you don't add/remove 
classes/interfaces/methods to it, and that passes the tests provided by 
Sun.

Obviously it says that it does not derive from any Sun source code or 
binary code, but that's something I'm being careful to avoid anyway.

It's a bit unclear as to what it means by 'specification' anyway; 
whether it's just the document or whether it's the document-and-APIs. 
I'd argue that if it's the former then it would be impossible to do so.

>> I was also working on it in stages; first, get the abstract
>> classes/interfaces together for the API,
>
> Don't forget that it's with JavaMail theres also concrete classes, 
> like the
> oft mentioned MimeMessage, which are part of the API too.
> Everything in javax.mail.* is part of the API.

Yes, I should have included the concrete ones as well.

>> But at a first cut, I was looking at JavaMail in itself, without any
>> extensions to that API.
>
> It'd be a hell of a lot of work, but if you do it properly I'm sure an 
> ASFL
> version of javaMail would be popular.

Somehow, I never go for the easy jobs ...

>> This is my problem; how can I implement the JavaMail API in a way that
>> is legally acceptable by the ASF? Is taking the signatures from the 
>> API
>> documentation legally the right way to go? Otherwise I don't see how
>> this would be possible.
>
> Yeah, agreed, I guess we ought to get some claification, have you read 
> the
> licence recently? does it give you any hints?

Read it above, think it's possible. But would like ASF legal advice on 
this. Also, I don't know how to get hold of the testing kits; is this 
something that Apache can do formally through Sun? And/or submit it for 
formal testing?

>> Obviously, I'm not using reverse engineering or using the source to do
>> the implementation; on the other hand, I'm also not bothering with
>> JavaDoc since I'm assuming that people know how to use it and it's 
>> just
>> the implementation that's required :-)
>
> Right, the trouble is that for a re-creation of javaMail to make any 
> sense
> it has to be a runtime replacement for javax.mail.*
> Therefore it has to duplicate every single class and method sig. 
> exactly.
> And you can't ever depend upon any classes in Sun's distribution 
> because
> that'd re-introduce precisely the licence dependance you are trying to
> avoid.

Presumably, public and protected are important; private and friendly 
are not?

>> I also belive that whilst they are documented, the com.sun
>> implementations do not form part of the API and therefore shouldn't be
>> cloned. I don't know if that's a right decision or not.
>
> Yes, the com.sun classes are the Reference Implementation (RI) of the
> interfaces and abstract classes which are intended to be implemented by
> implementations ;-) . the javax.mail ones are not. The scope of this 
> project
> (and to some extent of James) *is* the com.sun classes, javax.mail is 
> not in
> the scope of James and may not even be within the scope of this effort.

True, but until a set of javax.mail interfaces exist and can be 
used/redistributed, it's going to make the implementation a lot more 
difficult ;-)

Any legal thoughts on this?

Alex.

Re: [JavaMail] re-engineering of JavaMail from specs?

[Danny Angus <da...@apache.org>]

Alex,

(BTW are you in Europe?)

> Yes, but the question I have is whether I can legally read Sun's API
> and then write an implementation of it. I'm not going to touch the
> source code, but there isn't any way of creating a JavaMail
> implementation using the PDF Spec alone; it simply doesn't provide
> enough code.

Well if others have typed in interfaces from the javadocs and not been "gone
after" I'd suggest that reading the javadocs is OK.
In addition it would be pretty much 100% impossible otherwise.
Read the licence and pay attention to the no reverse engineering bits..
At the end of the day if you're really worried someone can ask the Board to
get legal opinion.


> I was also working on it in stages; first, get the abstract
> classes/interfaces together for the API,

Don't forget that it's with JavaMail theres also concrete classes, like the
oft mentioned MimeMessage, which are part of the API too.
Everything in javax.mail.* is part of the API.

> and then work on the
> implementation for validation etc, sending mail. As I mentioned
> previously, I have some mail implementation classes kicking around from
> before so I have something to work with -- alternatively, there's some
> stuff in the JAMES implementation which may work.

Not so's you'd notice ;-)

> > IMO anything else is deviating from the API spec, and probably ought
> > to be
> > discussed and agreed first.
>
> I agree completely -- the JavaMail has some glitches, but needs to be
> there 'warts and all'. I've been thinking what I like/don't like in the
> API, and have been coming to the conclusion that either JavaMail can
> sit on the AlexMailAPI, or vice versa. (The advantage of the latter
> means that it should be portable to other servers as well.)

Vice-versa is pretty much what I've been trying to get across.

> But at a first cut, I was looking at JavaMail in itself, without any
> extensions to that API.

It'd be a hell of a lot of work, but if you do it properly I'm sure an ASFL
version of javaMail would be popular.

> This is my problem; how can I implement the JavaMail API in a way that
> is legally acceptable by the ASF? Is taking the signatures from the API
> documentation legally the right way to go? Otherwise I don't see how
> this would be possible.

Yeah, agreed, I guess we ought to get some claification, have you read the
licence recently? does it give you any hints?

> Obviously, I'm not using reverse engineering or using the source to do
> the implementation; on the other hand, I'm also not bothering with
> JavaDoc since I'm assuming that people know how to use it and it's just
> the implementation that's required :-)

Right, the trouble is that for a re-creation of javaMail to make any sense
it has to be a runtime replacement for javax.mail.*
Therefore it has to duplicate every single class and method sig. exactly.
And you can't ever depend upon any classes in Sun's distribution because
that'd re-introduce precisely the licence dependance you are trying to
avoid.

> I also belive that whilst they are documented, the com.sun
> implementations do not form part of the API and therefore shouldn't be
> cloned. I don't know if that's a right decision or not.

Yes, the com.sun classes are the Reference Implementation (RI) of the
interfaces and abstract classes which are intended to be implemented by
implementations ;-) . the javax.mail ones are not. The scope of this project
(and to some extent of James) *is* the com.sun classes, javax.mail is not in
the scope of James and may not even be within the scope of this effort.

d.

Re: [JavaMail] re-engineering of JavaMail from specs?

[Alex Blewitt <Al...@ioshq.com>]

>> So, in order to meet the specs, which should I follow? Should I 
>> provide
>> all public  methods listed in the API documentation, or just those 
>> that
>> are directly mentioned in the PDF? My fear is that if I do the latter,
>> then we'll end up failing the TCK since it won't have all the methods
>> the TCK is expecting.
>
> Although I still have *huge* reservations about the quantity of work 
> you are
> taking on, and how worthwhile it will actually turn out to be, I'm 
> afraid
> that think you have to do both or nothing. You'll have to abide by 
> both the
> javadocs and the descriptive specification.
> Anyone using your clone of javaMail will expect it to honour Sun's
> documentation in *exactly* the way they would the published API.

Yes, but the question I have is whether I can legally read Sun's API 
and then write an implementation of it. I'm not going to touch the 
source code, but there isn't any way of creating a JavaMail 
implementation using the PDF Spec alone; it simply doesn't provide 
enough code.

I was also working on it in stages; first, get the abstract 
classes/interfaces together for the API, and then work on the 
implementation for validation etc, sending mail. As I mentioned 
previously, I have some mail implementation classes kicking around from 
before so I have something to work with -- alternatively, there's some 
stuff in the JAMES implementation which may work.

> IMO anything else is deviating from the API spec, and probably ought 
> to be
> discussed and agreed first.

I agree completely -- the JavaMail has some glitches, but needs to be 
there 'warts and all'. I've been thinking what I like/don't like in the 
API, and have been coming to the conclusion that either JavaMail can 
sit on the AlexMailAPI, or vice versa. (The advantage of the latter 
means that it should be portable to other servers as well.)

But at a first cut, I was looking at JavaMail in itself, without any 
extensions to that API.

> After all there is still some lack of clarity about how far this 
> project is
> about creating a "pure" implementation and how much it is open to
> enhancements, and that's just with regard to implementations and the 
> "clean
> room" re-creation of interfaces, never mind what you are proposing, 
> which is
> a fully blown re-creation of existing API classes, without (because I
> believe it is expressly prohbited by the licence) reverse engineering 
> or
> reference to the source code.

This is my problem; how can I implement the JavaMail API in a way that 
is legally acceptable by the ASF? Is taking the signatures from the API 
documentation legally the right way to go? Otherwise I don't see how 
this would be possible.

Obviously, I'm not using reverse engineering or using the source to do 
the implementation; on the other hand, I'm also not bothering with 
JavaDoc since I'm assuming that people know how to use it and it's just 
the implementation that's required :-)

I also belive that whilst they are documented, the com.sun 
implementations do not form part of the API and therefore shouldn't be 
cloned. I don't know if that's a right decision or not.

Alex.

RE: [JavaMail] re-engineering of JavaMail from specs?

[Danny Angus <da...@apache.org>]

Alex,

> So, in order to meet the specs, which should I follow? Should I provide
> all public  methods listed in the API documentation, or just those that
> are directly mentioned in the PDF? My fear is that if I do the latter,
> then we'll end up failing the TCK since it won't have all the methods
> the TCK is expecting.


Although I still have *huge* reservations about the quantity of work you are
taking on, and how worthwhile it will actually turn out to be, I'm afraid
that think you have to do both or nothing. You'll have to abide by both the
javadocs and the descriptive specification.
Anyone using your clone of javaMail will expect it to honour Sun's
documentation in *exactly* the way they would the published API.

IMO anything else is deviating from the API spec, and probably ought to be
discussed and agreed first.
After all there is still some lack of clarity about how far this project is
about creating a "pure" implementation and how much it is open to
enhancements, and that's just with regard to implementations and the "clean
room" re-creation of interfaces, never mind what you are proposing, which is
a fully blown re-creation of existing API classes, without (because I
believe it is expressly prohbited by the licence) reverse engineering or
refrence to the source code.

d.