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

[Bill Shannon <bill.shannon@xxxxxxxxxx>]

Patrick Reinhart wrote on 10/21/19 10:18 PM:
> 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 bundle can depend on those implementation classes without
re-exporting them to the user of the API.

>> 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.
> 
> I also agree with that point.
> 
>> 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.
> 
> 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...

I don't understand the scenario you're concerned about.

You put the API classes in the spec-defined package and you put the
implementation classes in your own package.

> 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?

Yes, everyone implementing the API needs to provide classes that match the
required AI signatures, and that include implementations consistent with the
spec.  You can create those classes from scratch, or you can derive those
classes from some other (e.g.) open source implementation of those classes
whose license meets your requirements.

It's the same thing you would do if you were providing your own implementation
of any of the modules in the JDK.