"Provides" and "with" type relationships

[Konstantin Barzilovich]

Sorry, I mean "great", not "grate".


> Yes. 'uses' and 'provides' are nothing more than static declarations  
> that configure java.util.ServiceLoader, so all questions can be resolved  
> by looking at the ServiceLoader spec:  
> http://download.java.net/java/jigsaw/docs/api/java/util/ServiceLoader.html
>
> Alex
>
> On 3/16/2016 10:24 AM, Konstantin Barzilovich wrote:
>> Sorry, if this question was asked before.
>> Does service implementation need to inherit service interface?
>>
>> Thanks,
>> Konstantin.
>>
>>> // Ignore last mail (mail client did a surprising thing)
>>>
>>> A 'provides' clause specifies two things: a service interface and a
>>> service implementation. Using those terms helps to avoid confusion.
>>>
>>> A service interface does not have to be an interface; it can be an
>>> abstract class or even (not recommended) a concrete class.
>>>
>>> A service implementation must not be an interface, or an abstract
>>> class; it must be a concrete class.
>>>
>>> Therefore, it's legal (but not recommended) for a concrete class to be
>>> specified as both service interface and service implementation. It's
>>> illegal for an interface (or abstract class) to be specified as both
>>> service interface and service implementation. JCK will be writing
>>> tests for edge cases like this.
>>>
>>> Alex
>>>
>>> On 3/15/2016 12:39 PM, Paul Benedict wrote:
>>>> Thanks for your response Alex. If I am understanding you correctly,
>>>> "provides" is "not constrained to be an interface" because it can be  
>>>> "a
>>>> single interface or abstract class". So shouldn't my concrete class  
>>>> for
>>>> "provides" be rejected by the compiler? And is it okay that both types
>>>> were identical?
>>>>
>>>> Cheers,
>>>> Paul
>>>>
>>>> On Tue, Mar 15, 2016 at 2:26 PM, Alex Buckley <alex.buckley at oracle.com
>>>> <mailto:alex.buckley at oracle.com>> wrote:
>>>>
>>>>     The first operand to 'provides' (the "service interface") is not
>>>>     constrained to be an interface by "Modules in the Java Language  
>>>> and
>>>>     JVM". This is because the spec of j.u.ServiceLoader ("a service is
>>>>     represented by a single type, that is, a single interface or
>>>>     abstract class").
>>>>
>>>>     The second operand to 'provides' (the "service implementation") is
>>>>     constrained not to be an interface or an abstract class by  
>>>> "Modules
>>>>     in the Java Language and JVM". This is also because of the spec of
>>>>     j.u.ServiceLoader ("provider classes must have a zero-argument
>>>>     constructor so that they can be instantiated during loading").
>>>>
>>>>     Bear in mind that the JCK team can easily set up abstract test  
>>>> cases
>>>>     like this. What they can't do is check whether YOUR application  
>>>> runs
>>>>     on JDK-9-with-Jigsaw, or whether arbitrary JARs on YOUR classpath
>>>>     work as automatic modules.
>>>>
>>>>     Alex
>>>>
>>>>
>>>>     On 3/15/2016 12:07 PM, Paul Benedict wrote:
>>>>
>>>>         module z {
>>>>               exports z;
>>>>               provides z.Main with z.Main;
>>>>         }
>>>>
>>>>         The SOTM says "Service-provider declarations can be further
>>>>         interpreted to
>>>>         ensure that providers (e.g., com.mysql.jdbc.Driver) actually  
>>>> do
>>>>         implement
>>>>         their declared service interfaces" (section 4, para. 8).
>>>>
>>>>         I see javac checking that they are related types, but javac is
>>>>         not checking
>>>>         that "provides" is an interface type. That is what I was
>>>>         expecting based on
>>>>         the reading material.
>>>>
>>>>         The other unexpected outcome was that provides/with allows the
>>>>         identical
>>>>         type. I don't know if that's intended, but please advise.
>>>>
>>>>         PS: I did go through the open tickets this time (thanks Alan)
>>>>         and do not
>>>>         see any similar reports. If I missed it, I apologize; just
>>>>         trying not to
>>>>         waste your time by reporting a duplicate.
>>>>
>>>>         Cheers,
>>>>         Paul
>>>>
>>>>
>>
>>


-- 
Thanks,
Konstantin.