Sybex CSG 11: Possible Erratum in the OCP Java SE 11 Developer Complete Study Guide

[Nyeng Gyang]

The return type of the stream() method of the ServiceLoader<S> class is Stream<ServiceLoader.Provider<S>>.

Does it matter that, on page 829 of the study guide, the study guide says that the return type of the stream() method of the ServiceLoader<S> class is Stream<Provider<S>> (rather than the return type mentioned above)?

Considering the fact that ServiceLoader.Provider<S> is an interface nested in the ServiceLoader<S> class and the fact that there is a java.security.Provider class in Java that is not even parameterized, I don't believe that Java has a Provider<S> type. Consequently, the Provider<S> type may not be used in lieu of the ServiceLoader.Provider<S> type, as the study guide does. In other words, the return type of the stream() method of the ServiceLoader<S> class is Stream<ServiceLoader.Provider<S>>, not Stream<Provider<S>>.

[Campbell Ritchie]

Nyeng Gyang wrote:. . .
Does it matter
. . .

Remember that the method will be declared as returning Stream<Provider<S>> in the source code (in the Java®16 version line 1443).

[Nyeng Gyang]

Campbell Ritchie wrote:Remember that the method will be declared as returning Stream<Provider<S>> in the source code (in the Java®16 version line 1443).

I did not realize that the method will be declared as returning Stream<Provider<S>>. Anyways, I just wonder why the method would return this type when (1) The Provider<S> type doesn't seem to exist in Java and (2) The Provider::get method reference in the study guide implies that it is equivalent to the following lambda: x -> x.get(), i.e., this get() method is an instance method that belongs to the ServiceLoader.Provider<S> type, rather than some apparently nonexistent Provider<S> type.

The point made in the foregoing point number 2 above is congruent with the fact that, in the statement below, when a ServiceLoader<T> instance invokes its stream() instance method, a stream of ServiceLoader.Provider<S> types, rather than a stream of Provider<S> types, is returned:

OptionalInt max = ServiceLoader.load(Tour.class)
                .stream()
                .map(Provider::get)
                .mapToInt(Tour::length)
                .max();

Another puzzle for me is how come the java.util.ServiceLoader.Provider import works for the Provider type? Shouldn't this import be for the ServiceLoader.Provider type, instead?

[Paul Clapham]

Your analysis of where the "Provider" type comes from is correct. And given this import:

import static java.util.ServiceLoader.Provider;

it can be referred to as "Provider" in Java code. In your post you mentioned an import but didn't show us that import. Perhaps the study guide doesn't show it to you either? At any rate this one will do.

[Nyeng Gyang]

Paul Clapham wrote:And given this import:

import static java.util.ServiceLoader.Provider;

it can be referred to as "Provider" in Java code. In your post you mentioned an import but didn't show us that import. Perhaps the study guide doesn't show it to you either? At any rate this one will do.

Your explanation that the ServiceLoader.Provider<T> type may be referred to as the Provider<T> type in Java code, when an appropriate import statement is used in such code, helps to clarify my second question. By the way, the study guide uses the following import:

import java.util.ServiceLoader.Provider;

The study guide informs that either this import or the one you gave (which is a static import) is okay for importing a static member into Java code (even though the study guide provides this information, I just found out that explicitly including the static keyword in the import statement is required if the imported static member is not a nested type, e.g., if the imported static member is a method; i.e., Java allows the omission of the static keyword in the import statement only when the imported static member is a nested type).

However, this explanation you provided doesn't assuage the non-clarity that underlies my first question, namely: Without the context that a Provider<T> type is nested in the ServiceLoader<T> type, it is confusing - as well as time-wasting to resolve this confusion - when a pedagogical text furnishes the signature for the stream() method of the ServiceLoader<T> class as in the point number 1, rather than the point number 2, below:

(1.) Stream<Provider<S>> stream()

(2.) Stream<ServiceLoader.Provider<S>> stream()

In fact, at this page, the Java API furnishes the signature in point number 2, rather than the one in point number 1, above as the signature for the method. I just wonder how many people learning Java or even, in fact, actively using Java to write production code will be looking at the code that implements the core Java APIs, in order to apprise themselves of the various import statements that various classes in these APIs employ to control namespaces in the code for the APIs?

Without the context that some piece of code uses an appropriate import statement in the code, in order to import the Provider<T> type that is nested in the ServiceLoader<T> type, furnishing the former type in a pedagogical text, as the return type of the stream() method of the ServiceLoader<T> class, is quite confusing as well as time-wasting indeed to people learning about this class and its methods.