Hi Martin,
Even if a library decide to do the duplication, it may still not work. Starting with Java 9, a service provider can be instantiated by invoking a public static method named "provider" in the provider declared in "module-info.class". This is an alternative to invoking the default public constructor. This alternative is very convenient when we want the provider to be a singleton for example. However the public static "provider" method is invoked only for services declared in "module-info.class", not for services declared in the old way. So if a service provider relies on that, it will not work on the class-path.
I see your point, but we're not living in a fully modularized Java world: If you insist on having a Jar reside on the module path only, this prevents others from using it on applications that are not fully modularized or that cannot be modularized (yet). Furthermore I don't really see a problem of duplication. Normally you don't have tons of service provider implementations in one Jar (IMO) so this shouldn't be too much hassle to have a few lines in your module descriptor AND in the provider configuration file under META-INF/services... To the singleton example you mentioned: I don't know if that really makes sense. To be compatible with fully-modular applications and those that aren't I'd extract the necessary parts from the provider implementation into a singleton class and use that one instead. In this case you still could have multiple instances of your provider implementation, and all of them internally use a singleton for configuration data or whatever...
Finally the consequence on putting a dependency on the class-path rather than the module-path is much larger than only "java.util.ServiceLoader". The behavior of any methods annotated @CallerSensitive in OpenJDK source code may be impacted. It includes for example "ClassLoader.getResource(String)". If a library depends on those methods behaving the way the behave when the file is loaded at a module, that library may be broken if put on the class-path.
Out of curiosity: Can you show an example that depends on such methods? I personally don't see a reason why a library should behave different if it is on the module path or class path...
So to summarize: putting a JAR file on the module-path or class-path has deep consequences. A developer way want either ways on intend (including putting a modularized JAR file on the class-path or a non-modularized JAR file on the module-path, yes the opposite of the "sane" way, there is use cases for that). Maven should not keep developers prisoners of black magic. We need control on that.
IMHO a library is buggy if it's *behavior* depends on whether it is being used on the module path or on the classpath. Just my thoughts... Kind regards Thorsten --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
