Re: "Provides" and "with" type relationships

[Alex Buckley]

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

Re: "Provides" and "with" type relationships

[Konstantin Barzilovich]

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

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

Re: "Provides" and "with" type relationships

[Konstantin Barzilovich]

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

Re: "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 > 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.

Re: "Provides" and "with" type relationships

[Alex Buckley]

There are also some improvements to make to the ServiceLoader API spec, 
and at that time we'll lock in alignment of API spec and JLS. 
(Consistent terminology; duplication of rules only where essential; 
appropriate "call outs" to module system concepts such as service binding).


Alex

On 3/17/2016 11:19 AM, Jonathan Gibbons wrote:

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

Re: "Provides" and "with" type relationships

[Alex Buckley]

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

Re: "Provides" and "with" type relationships

[Alex Buckley]

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 not OK if the same type is 
specified as both service interface and service implementation, and JCK 
will be writing tests for that, I promise.


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

Re: "Provides" and "with" type relationships

[Paul Benedict]

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

Re: "Provides" and "with" type relationships

[Alex Buckley]

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

"Provides" and "with" type relationships

[Paul Benedict]

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