|Re: [jakartaee-platform-dev] lassNotFoundException: com.sun.mail.util.PropUtil when using javax.mail.internet.InternetAddress|
Hi Bill, On 2019-10-21 23:41, Bill Shannon wrote:
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.
I agree with this as long as those classes are part of the API bundle itself as they would be
a hidden package when using a JPMS in the future.
The API classes (in some cases) are real concrete classes. Nothinglimits the code that's inside those real concrete classes as long as theexternally visible behavior is that required by the specification.
I also agree with that point.
To implement the Mail API yourself, you create your own versions ofthese 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 thespec.
Here our views differ I think. I was looking to the core in a JPMS way, and in this view I'm not allowed to create my own version of this definition class as this would produce a split package scenario as I would need to put that class in a package, that belongs to
the API module in that case...Your explanations imply to me that every one that implements the Mail API in that case also needs to create a complete copy of the API classes with exception of the ones implemented differently by the specific implementer then?
Back to the top