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

[Patrick Reinhart <patrick@xxxxxxxxx>]

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.

Attachment: signature.asc
Description: OpenPGP digital signature