@twasyl commented on Thu Mar 23 2017
Version
- vert.x core: 3.4.1
- vert.x web: 3.4.1
Context
Hello,
I'm currently trying to migrate SlideshowFX to JDK9 (build 161 with Jigsaw).
The application embeds Vert.x in order to provide a WebServer. Until now I have been using Vert.x 3.3.3 and the application was running well. Now I'm trying to use versions 3.4.0 and 3.4.1 and when starting the application, I've got the following error and the application can't boot:
Error occurred during initialization of boot layer
java.lang.module.FindException: java.io.IOException: Provider class moduleName = io.vertx.ext.web.handler.VirtualHostHandler-module not in module
Caused by: java.io.IOException: Provider class moduleName = io.vertx.ext.web.handler.VirtualHostHandler-module not in module
When looking at the source code of vertx-web
, I can see the META-INF/services/org.codehaus.groovy.runtime.ExtensionModule
file. As specified by the ServiceLoader class, such files are used in order to define services not developed as JPMS modules but running as JAR files on the classpath. I suppose the addition of this file is intentional by the Vert.x developers but I can't figure out how to be able to start SlideshowFX again.
Have you encountered such issue and were able to fix it?
Thanks
@vietj commented on Thu Mar 23 2017
Have you tried to remove the META-INF/services/org.codehaus.groovy.runtime.ExtensionModule
file from the jar to see if it fixes the problem ?
I'm wondering also how this is related to the issue you are reporting. Not saying it's not related, but I don't see much the relationship right now.
@twasyl commented on Thu Mar 23 2017
I tried your suggestion and it leads me to this message now:
Error occurred during initialization of boot layer
java.lang.module.FindException: java.io.IOException: Provider class moduleName = io.vertx.ext.auth.User-module not in module
Caused by: java.io.IOException: Provider class moduleName = io.vertx.ext.auth.User-module not in module
So I removed the META-INF/services/org.codehaus.groovy.runtime.ExtensionModule
file from the vertx-auth
JAR and I am now able to start a server.
I don't really know how it is related to the issue as I don't understand the use of the org.codehaus.groovy.runtime.ExtensionModule
files from a Vert.x point of view. Seeing this from a JDK9 POV and reading the ServiceLoader javadoc, it is mentionned the following:
Now suppose that com.example.impl.StandardCodecs is an implementation of the CodecSet service and developed as a module. In that case then the module with the service provider module will declare this in its module descriptor:
provides com.example.CodecSet with com.example.impl.StandardCodecs;
On the other hand, suppose com.example.impl.StandardCodecs is packaged in a JAR file for the class path then the JAR file will contain a file named:
META-INF/services/com.example.CodecSet
that contains the single line:
com.example.impl.StandardCodecs # Standard codecs
So if these org.codehaus.groovy.runtime.ExtensionModule
files are not used in order to prepare the Vert.x project for JDK9, maybe they come in conflict with the JPMS of JDK9.
@vietj commented on Thu Mar 23 2017
thanks for investigating it.
can you provide a small reproducer ?
Vert.x uses vanilla Groovy extension modules, so I think we need to investigate Groovy extension modules and Java 9
@twasyl commented on Thu Mar 23 2017
Here is a simple reproducer (vertx-jdk9.zip) that can be imported in IDEA EAP and using a JDK 9 EA build. Trying to start the Application
class will lead to the errors.
Cleaning the JARs to remove the META-INF/services
folders will let the application boot.
@vietj commented on Thu Mar 23 2017
thanks, I hope it's easy to investigate :-)
@vietj commented on Fri Apr 07 2017
we should reach out the Groovy community to see if they are going to support Java 9 actually, it seems more like a Groovy issue than a Vert.x issue
@pmlopes commented on Fri Apr 07 2017
Sure, but we need some action on our side since this will block us from running on JDK9 once it's out aprox end September.
@twasyl commented on Fri Apr 07 2017
I don't know if you're interested in knowing it but it seems asciidoctorj
which uses jruby
underneath has similar issues as I also use it in SlideshowFX. It seems the META-INF/services
folder will have a key role under JDK9.
@karianna commented on Fri Apr 07 2017
You can join OpenJDK's quality outreach programme (https://wiki.openjdk.java.net/display/quality/Quality+Outreach) to work directly with Oracle to resolve issues.