"Provides" and "with" type relationships

[Jonathan Gibbons]

Konstantin,

The compiler checks that the service implementation implements the 
service type.
I have confidence that when the final specification is published, there 
will be suitable assertions (either explicit or implicit) to back up 
that check.

-- Jon

On 03/17/2016 06:02 AM, Konstantin Barzilovich wrote:
>
> Thanks.
> It is described in API spec in detail.
> But from compiler point of view, it is allowed to use implementation 
> without inheritance.
> It would be grate to add some of these statements to compiler spec, if 
> it is possible.
>
> Thanks,
> Konstantin.
>
>> 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
>>>>>
>>>>>
>>>
>>>
>
>