Please can we be more precise when using the terms RI (Refrence Implementation) and API
The Javax.mail.* packages are the JavaMail API The com.sun.* mail classes are the RI. At the start of this I raised concerns about the nature of JavaMail and the appropriateness of this operation. In the light of this development I'd like to raise some of the points again. 1/ JavaMail is distibuted as API and RI by Sun for the convenience of it's users. 2/ The API itself consists of many more concrete classes, and many fewer Interfaces than most other J2EE API's. 3/ The concrete classes encapsulate a lot of RFC compliance code. 4/ We know from discussions regarding Tomcat that the behaviour of a RI itself forms "case law" and sets precedence about the expected behaviour of other implementations. 5/ Any acceptable copy of the JavaMail API must comply with the published specification, being both the wordy specification and the javadocs. It must also exhibit substantially the same behaviour as Suns product, and any implementation must be consistent with the RI. Now Alex says.. > The dependency is on the InvalidArgumentException and > NullArgumentException. I originally put those in since when they become > internationalised, changes made to those classes will have immediate > benefit to the JavaMail API. Alex we (and you) have no jurisdiction to make any changes whasoever to the API, specifically including method signatures. What is acceptable is for the internal implementation of the expected behaviour to be implemented in any way we choose, but that any dependance not specified by the API should be satisfied internally and not apparent in any way to any user of the API. That is to say we could use components from many sources, but our resulting mailapi.jar should be a direct replacement for Sun's one with no additional requirements. > I do not believe that the specs package cannot include classes outside of > the javax. namespace; indeed, the Sun RI ships with a whole bunch of > com.sun classes as is. There isn't any reason why JavaMail couldn't ship > with an org.apache class or two instead. The API only consist of the javax.mail.* packages, and only depends upon java.* and javax.* The com.sun classes are the refrence implementation and though they depend upon the API the API does not depend upon them. > The issue at stake is that the bug also exists in the Sun RI. Actually if it exists it is in the API not the RI. You are at liberty to "fix" it but this would then be a deviation from the API behavoiur which our user would have to be informed of, for the sake of their sanity if nothing else. > The absolute question is: what are we trying to achieve in the JavaMail > API reimplementation? Copy it byte-for-byte, including any bugs that are > present in the JavaMail implementation? Or provide something that behaves > correctly as per the JavaDoc? My take on this is that we should implement > to the spec, and not try to represent every bug in the RI, since the > latter will be a moving target. Well at least now you're beginning to realise why it is not a job to be undertaken lightly. > > > These may seem minor but they are symptomatic of a coding > > > approach that may lead to other deviations and I think the > > > entire patch should be reviewed in detail. If someone steps > > > up to do that then it may be appropriate to commit this to a > > > separate branch until done. > > Always nice not to be trusted :-) This has little or nothing to do with trust, Apache projects are meritocracies and operate a system of peer review. You have allegedly made an error of judgement based upon an apparent difficulty in understanding what is the JavaMail API and what is it's implementation and what is appropriate for your work on each part. This has, quite rightly, been picked up by peer review and also quite rightly it has been suggested that the the rest of your patch be reviewed in detail in case the same assumtions are manifested elsewhere. We're here to do this thing correctly, whether or not that offends you. > I have always been very careful to implement the JavaMail APIs based on the JavaDoc In which case why did you add a dependancy which doesn't exist there? d.
