Re: "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.buck...@oracle.com
<mailto:alex.buck...@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