So my understanding is that because this file is found in META-INF/services, the JDK interprets its contents as being a service class name provider, which is it not. We have quite a few files in there which are "Groovy services" but nothing related to "Java services":META-INF/services/javax.
script.ScriptEngineFactory: references the JSR 223 class name. Service in the JDK semantics.META-INF/services/org.apache. groovy.plugin.GroovyRunner : not quite sure why it's there, seems rather new to me, and references a real class (TestNgRunner)META-INF/services/org. codehaus.groovy.runtime. ExtensionModule : Groovy's extension module file. Doesn't reference services but it's more a properties file referencing other class namesMETA-INF/services/org. codehaus.groovy.source. Extensions : possible Groovy compiler extension file names listed here. Not a service.META-INF/services/org. codehaus.groovy.transform. ASTTransformation : a list of class names, which are not JDK services either.So I have no clue why the JDK needs to read all those files and make sure the service classes exist. But it would be a breaking change to move those files somewhere else.2017-12-03 19:01 GMT+01:00 Cédric Champeau <firstname.lastname@example.org>:This file is used by Groovy internally, there's no reason for the JDK to interpret its contents since it has only a meaning for Groovy. In short, it declares the list of extensions recognized by the Groovy compiler. That it prevents loading as a module is rather strange.2017-12-03 16:37 GMT+01:00 Ceki Gulcu <email@example.com>:Hi all,
Referring to a discussion on the maven users list , it appears that
removing the file META-INF/services/org.codehaus
.groovy.source.Extensions from groovy-2.4.13.jar allows Java 9 to successfully load groovy-2.4.13.jar as an auto-module.
ensions file contains the lone word "groovy" instead of a fully qualified class name.