Re: [jakartaee-platform-dev] lassNotFoundException: com.sun.mail.util.Pr

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

Why do you think it's wrong that the API classes are referring to
implementation specific classes?  There's nothing in the API definition
that says the API can't use implementation specific classes.

The API classes (in some cases) are real concrete classes.  Nothing
limits the code that's inside those real concrete classes as long as the
externally visible behavior is that required by the specification.

To implement the Mail API yourself, you create your own versions of
these real concrete classes and put whatever code in them that you need.
You don't need to, and aren't expected to, reuse the existing API definition
classes.  As long as your versions of these classes have the required API
signatures and the required behavior, you've successfully implemented the
spec.


Patrick Reinhart wrote on 10/21/19 1:32 PM:
> 
> Hi Bill,
> 
> I was maybe not clear enough...
> 
> It is absolutely clear to me that the _implementer_ is free to use any
> non public implementation-specific classes in order to implement the
> API. What I think is wrong in this case, is that the _API_ is referring
> _implementation-specific_ classes in that case. That said, it is also no
> problem if the API contains non public implementation classes, that are
> not visible to me as an implementer though.
> 
> But what if I would like to implement this Mail API (for example within
> a test case), how would I implement the InternetAddress behavior as I do
> not have any access to those non public classes then?
> 
> -Patrick
> 
> 
> Am 21.10.19 um 21:21 schrieb Bill Shannon:
>> Your expectations are wrong.
>>
>> You need a complete functional implementation of the API.
>>
>> There's nothing that prevents an API from being implemented by using any
>> number of non-public, implementation-specific classes.  For example, parsing
>> of internet email addresses could be implemented by using a separate internet
>> address parser class, perhaps provided by a different project, but exposed to
>> users through the javax.mail.internet.InternetAddress class.
>>
>> In such a case, all of the implementation classes would be hidden from an
>> application that only wanted to see the standard javax.mail classes, e.g.,
>> because it was compiling against the API jar file.
>>
>> But you're not just compiling against the API classes.  You need the API
>> classes to be functional.  You need a complete implementation, without
>> knowing the details of how it is implemented.
> 
>