Error when running dev-latest.jar

[trevorgerhardt]

dev-latest.jar is failing to run in Cypress tests (example here). This error is being thrown on startup:

##[error]Exception in thread "main" java.util.ServiceConfigurationError: javax.imageio.spi.ImageWriterSpi: Provider com.sun.media.imageioimpl.plugins.jpeg.CLibJPEGImageWriterSpi could not be instantiated
    at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:581)
    at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:803)
    at java.base/java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:721)
    at java.base/java.util.ServiceLoader$3.next(ServiceLoader.java:1394)
    at java.desktop/javax.imageio.spi.IIORegistry.registerApplicationClasspathSpis(IIORegistry.java:188)
    at java.desktop/javax.imageio.spi.IIORegistry.<init>(IIORegistry.java:113)
    at java.desktop/javax.imageio.spi.IIORegistry.getDefaultInstance(IIORegistry.java:134)
    at java.desktop/javax.imageio.ImageIO.<clinit>(ImageIO.java:66)
    at com.conveyal.analysis.BackendMain.startServer(BackendMain.java:52)
    at com.conveyal.analysis.BackendMain.main(BackendMain.java:43)
Caused by: java.lang.IllegalArgumentException: vendorName == null!
    at java.desktop/javax.imageio.spi.IIOServiceProvider.<init>(IIOServiceProvider.java:76)
    at java.desktop/javax.imageio.spi.ImageReaderWriterSpi.<init>(ImageReaderWriterSpi.java:233)
    at java.desktop/javax.imageio.spi.ImageWriterSpi.<init>(ImageWriterSpi.java:213)
    at com.sun.media.imageioimpl.plugins.jpeg.CLibJPEGImageWriterSpi.<init>(CLibJPEGImageWriterSpi.java:84)
    at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
    at java.base/java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:779)

Is this due to the new build system?

[abyrd]

Yes, JAI is super touchy about metadata included in the JAR and it is entirely possible Gradle is not setting that metadata. I should be able to fix it.

@ansoncfit also reports that these worker builds fail to start up, which might be the same problem.

I've been building these locally since I started using Gradle and have rarely run them from JARs, so there will likely be a few iterations of ironing out the JAR packaging.

[abyrd]

I have grabbed the JAR built with the patch v5.10.0-7-g0121a55 and it seems to start cleanly. It's not clear to me though why I need to manually inject this metadata into the JAR. The stacktrace shows it reading the vendor name from com.sun.media.imageioimpl.common.PackageUtil in which this is a hard-coded literal field. Seems like the implementation I see in the IDE was getting replaced somehow when packaging the JAR.

[abyrd]

I'm wondering if in our decade-long use of Geotools we've failed to follow the migration to JAI-EXT. Our dependencies seem to contain a JAI implementation with a hard-coded vendor name, which we're not using at runtime. We might have to do some setup to register this implementation instead of the long-abandoned Oracle one. Some links to dig into:

https://docs.geotools.org/stable/userguide/tutorial/raster/jaiext.html#jaiext https://github.com/geosolutions-it/jai-ext https://github.com/geotools/geotools/wiki/Replace-JAI-Background-Discussion https://docs.geotools.org/latest/javadocs/org/geotools/image/jai/package-summary.html

The last one says services may not be registered in some circumstances, which may include Shaded / Shadow JARs.

[abyrd]

As a stopgap though, injecting these vendor name strings into the JAR metadata might keep it running without the potential disruption of swapping out our image reading/writing implementation. If this version v5.10.0-7-g0121a55 works as a worker or backend then it might be a viable solution. Others, please feel free to test, and I will look into it more tomorrow.

[ansoncfit]

Using v5.10.0-7-g0121a55, worker exits with:

OpenJDK 64-Bit Server VM Corretto-8.265.01.1 (build 25.265-b01, mixed mode)
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/conveyal/r5/R5Main has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)

[trevorgerhardt]

Before uploading the JARs in the Github Action should we run the jars to verify they can be run?