Normally you specify what a provided service in module is. Thus the java
compiler has no reason to look at random files in this directory. In
fact the module info makes it very specific what to look for. That is
why I doubt javac will have a problem, unless specified as not valid.
And I have
Jochen makes a good point regarding the source of the complaint being
Maven rather than the JDK. However, Maven relies on JDK module support
to know how to populate the classpath/modulepath prior to compilation.
It essentially invokes java.lang.module.ModuleFinder.of(path).findAll().
Thus,
Oh thanks for the clarification, Jochen, I didn't realize the problem was
with Maven itself. I think Maven over-interprets the spec. It's not because
you find a file in `META-INF/services` that it *must* be a service
descriptor.
Now for the extension mechanism, for sure we need to check what it
Just to clarify things... This is a maven plugin complaining, not JDK9,
as I see it. Afaik the plugin tries to create a module configuration for
groovy and cannot interpret the services provided in those directories.
JDK9 would not care, unless you say your module is providing a certain
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
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":
Yes. But. The current content breaks the expected semantics of the
ServiceLoader mechanism.
That is, a line in a file such as META-INF/services/com.acme.Foo, is
expected to be
- a fully classified classname
- with no-args constructor
- that implements (if the filename denotes an interface) or
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
Hi all,
Referring to a discussion on the maven users list [1], 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.
The org.codehaus.groovy.source.Extensions
