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

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

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.


Patrick Reinhart wrote on 10/18/19 11:56 PM:
> Hi Bill,
> 
> In that specific failing test the goal ist to check if our logic is returning
> the correct InternetAddress oobjects based on entries within a database by using
> a public static API method of InternetAddress. Also I would then implement those
> parts of the implementation within the test project though.
> 
> I would expect of a API to not throw any ClassNotFound exception when creating
> any of the provided classes. I accept to get any exceptions of type "no
> implementation found" of course...
> 
> 
> In my case the test szenario we pass an String containing multiple Email
> addresses delemited by a custom delemitor. And we want to test if those
> addresses have been correctly parsed....
> 
> Wintin the tested Logic the method
> javax.mail.internet.InternetAddresses.create(String) is being called, wich leads
> to an error with the JakarataEE API and DOES work with the JavaEE API artifact.
> 
> Anyway, My pont is the I not expect that API does refer classes of the API
> implementer.
> 
> 
> -Patrick
> 
> 
> 
> 
> 
> 
> On 2019-10-18 08:54, Bill Shannon wrote:
>> If your unit test depends on all of Jakarta EE being available for testing,
>> then you're going to need to find a way to do the unit testing by running
>> a complete app server as a separate program; no set of jar files is likely
>> to do that for you.
>>
>> If your unit test depends on only some of the APIs from Jakarta EE, then
>> depending on which APIs you might be able to find a standalone implementation
>> of those APIs that you can run inside the unit testing framework.
>>
>> In particular, if you are trying to do unit testing that depends on Jakarta
>> Mail, you can use the com.sun.mail:jakarta.mail jar file for testing, which
>> contains a complete implementation of Jakarta Mail.
>>
>>
>> Patrick Reinhart wrote on 10/17/19 11:37 PM:
>>> The problem happens in test phase of our build after the compilation. But
>>> comparing the both libraries (old and new one) those where different content
>>> wise. It is just that the current behavior has changed now...
>>>
>>> What would be the correct unit test dependency in that case?
>>>
>>> Best regards Patrick
>>>
>>>> Am 18.10.2019 um 05:03 schrieb Bill Shannon <bill.shannon@xxxxxxxxxx>:
>>>>
>>>