AndresCheers,Right. My gut feeling tells me META-INF/services should be used as intended, this would mean breaking compatibility by moving existing files that are not service providers, as noted by Cedric. This change should be made in the 3.x branch and beyond IMHO.But it's also true we don't know the exact reason why META-INF/services/org.codehaus
.groovy.source.Extensions is causing trouble and not the other files.------------------------------ -------------
Java Champion; Groovy Enthusiast
JCP EC Associate Seat
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and those who don't.
To understand recursion, we must first understand recursion.On Sun, Dec 3, 2017 at 12:13 PM, Cédric Champeau <firstname.lastname@example.org> wrote: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.g roovy.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.ExtensionModul e : 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.ASTTransform ation : 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 <email@example.com>: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 <firstname.lastname@example.org>: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.