JDK 9 ServiceLoader bug

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JDK 9 ServiceLoader bug

Chris Dennis
Hi All,

I’ve found what I believe could (or should) be considered a bug with the way the ServiceLoader interacts with the classpath in JDK 9.  Consider the following code:

====================
package example;

import java.util.ServiceLoader;

public class Main {
    public static void main(String[] args) {
        ServiceLoader.load(MyService.class).forEach(s -> System.out.println(s + " : " + s.getClass().hashCode()));;
    }
}
====================

where MyService is an empty interface and MyServiceImpl is an associated empty implementation.  If we JAR the compiled results up with a suitable services declaration and then make two copies of the resultant jar the following behaviors are seen:

[cdennis@Chriss-MacBook-Pro services-test]$ /usr/libexec/java_home -v 1.8 -exec java -showversion -cp one.jar:one.jar example.Main
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)

example.MyServiceImpl@16b98e56 : 2129789493

[cdennis@Chriss-MacBook-Pro services-test]$ /usr/libexec/java_home -v 1.8 -exec java -showversion -cp one.jar:two.jar example.Main
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)

example.MyServiceImpl@16b98e56 : 2129789493

[cdennis@Chriss-MacBook-Pro services-test]$ /usr/libexec/java_home -v 9 -exec java -showversion -cp one.jar:one.jar example.Main
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+159)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+159, mixed mode)
example.MyServiceImpl@6108b2d7 : 1449621165

[cdennis@Chriss-MacBook-Pro services-test]$ /usr/libexec/java_home -v 9 -exec java -showversion -cp one.jar:two.jar example.Main
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+159)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+159, mixed mode)
example.MyServiceImpl@6bf256fa : 357863579
example.MyServiceImpl@1a407d53 : 357863579

Since I’m not using the module path here (and neither of my jars are modular) I would expect to see the same behavior from JDK 9 as I get in 8 (and as is specified in both Javadocs):

"If a particular concrete provider class is named in more than one configuration file, or is named in the same configuration file more than once, then the duplicates are ignored. The configuration file naming a particular provider need not be in the same JAR file or other distribution unit as the provider itself. The provider must be visible from the same class loader that was initially queried to locate the configuration file; note that this is not necessarily the class loader from which the file was actually loaded.”

This will obviously cause confusion for anyone using the ServiceLoader to load singleton services who is not currently in total control of their classpath.  Dependencies that are both present and shaded would cause a problem for example.

Thanks,

Chris Dennis
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JDK 9 ServiceLoader bug

Alan Bateman
On 16/03/2017 21:06, Chris Dennis wrote:

> Hi All,
>
> I’ve found what I believe could (or should) be considered a bug with the way the ServiceLoader interacts with the classpath in JDK 9.
Thanks for the mail. There is indeed a bug in that it is not handling
duplicates on the class path. I'll create a bug for this, assume it will
be fixed in JDK 9 as it is regression.

-Alan
Loading...