Spring Cloud Function on GCP not compatible with Spring Boot 4.x

[btrajkovski-mms]

Describe the bug
After upgrading to Spring Boot 4.0.3 and also spring-cloud-function-adapter-gcp to version 5.0.1. Deployment to GCP no longer works. I tried both gen1 and gen2 options in GCP.

Issue seems to be pretty much the same as #1320 but that one is closed already. And I am also providing a minimum reproducible example here.

I am getting following exception during startup of the function:

Exception in thread "main" java.lang.RuntimeException: Could not construct an instance of org.springframework.cloud.function.adapter.gcp.GcfJarLauncher: java.lang.reflect.InvocationTargetException
	at com.google.cloud.functions.invoker.BackgroundFunctionExecutor.forClass(BackgroundFunctionExecutor.java:134)
	at com.google.cloud.functions.invoker.BackgroundFunctionExecutor.forClass(BackgroundFunctionExecutor.java:124)
	at com.google.cloud.functions.invoker.runner.Invoker.startServer(Invoker.java:319)
	at com.google.cloud.functions.invoker.runner.Invoker.startServer(Invoker.java:241)
	at com.google.cloud.functions.invoker.runner.Invoker.main(Invoker.java:124)
Caused by: java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481)
	at com.google.cloud.functions.invoker.BackgroundFunctionExecutor.forClass(BackgroundFunctionExecutor.java:131)
	... 4 more
Caused by: java.lang.ExceptionInInitializerError
	at org.springframework.boot.loader.net.protocol.jar.Handler.openConnection(Handler.java:46)
	at java.base/java.net.URL.openConnection(URL.java:1094)
	at org.springframework.boot.loader.net.protocol.jar.JarUrlClassLoader.getJarFile(JarUrlClassLoader.java:183)
	at org.springframework.boot.loader.net.protocol.jar.JarUrlClassLoader.definePackage(JarUrlClassLoader.java:146)
	at org.springframework.boot.loader.net.protocol.jar.JarUrlClassLoader.definePackageIfNecessary(JarUrlClassLoader.java:129)
	at org.springframework.boot.loader.net.protocol.jar.JarUrlClassLoader.loadClass(JarUrlClassLoader.java:102)
	at org.springframework.boot.loader.launch.LaunchedClassLoader.loadClass(LaunchedClassLoader.java:91)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
	at org.springframework.cloud.function.adapter.gcp.GcfJarLauncher.<init>(GcfJarLauncher.java:46)
	... 10 more
Caused by: java.lang.IllegalStateException: java.net.MalformedURLException: unknown protocol: nested
	at org.springframework.boot.loader.net.protocol.jar.JarUrlConnection.<clinit>(JarUrlConnection.java:67)
	... 19 more
Caused by: java.net.MalformedURLException: unknown protocol: nested
	at java.base/java.net.URL.<init>(URL.java:681)
	at java.base/java.net.URL.<init>(URL.java:569)
	at java.base/java.net.URL.<init>(URL.java:516)
	at java.base/java.net.JarURLConnection.parseSpecs(JarURLConnection.java:175)
	at java.base/java.net.JarURLConnection.<init>(JarURLConnection.java:158)
	at org.springframework.boot.loader.net.protocol.jar.JarUrlConnection.<init>(JarUrlConnection.java:92)
	at org.springframework.boot.loader.net.protocol.jar.JarUrlConnection.<clinit>(JarUrlConnection.java:64)
	... 19 more

Sample
Providing the Spring Boot cloud functions with deployment script to GCP (check deploy.sh)

example-project.zip

[yannissauzeau-netizen]

Same issue here with Spring Boot 4.x and spring-cloud-function-adapter-gcp 5.0.1 — same root cause as #1320 where the GCF invoker's classloader starts up before Spring Boot's nested: protocol handler gets registered. I tested the 4.3.1 adapter workaround and it does get things working again, but it would be great to see a proper fix land in the 5.x line so we're not stuck on a mismatched version.

[Laksuh]

Hi folks, we had the same issue when upgrading to spring boot 4. Since we could not imagine this still being a problem we tried to figure it out. Unfortunately this is still an issue...
Apparently there are two issues:

1. GcfJarLauncher never registers the nested URL protocol

GcfJarLauncher's constructor in 5.0.2 builds a LaunchedClassLoader directly without going through Launcher.launch(). As a result, Handlers.register() (which sets java.protocol.handler.pkgs so the JVM can find nested.Handler) is never called. Setting it explicitly via JAVA_TOOL_OPTIONS=-Djava.protocol.handler.pkgs=org.springframework.boot.loader.net.protocol did not fix it for us — the property-based class lookup was unreliable in this environment for reasons we couldn't pin down.

With the help of claude we could find a workaround by adding a subclass GcfJarLauncher and register the handlers programmatically via URL.setURLStreamHandlerFactory in a static initializer, then point --entry-point at the subclass. This hands the JVM already-instantiated Handler objects, bypassing the Class.forName lookup entirely.

  import java.net.URL;
  import org.springframework.boot.loader.net.protocol.Handlers;
  import org.springframework.cloud.function.adapter.gcp.GcfJarLauncher;

  public class BootstrappingGcfLauncher extends GcfJarLauncher {

      static {
          try {
            URL.setURLStreamHandlerFactory(protocol -> switch (protocol) {
                case "nested" -> new org.springframework.boot.loader.net.protocol.nested.Handler();
                case "jar" -> new org.springframework.boot.loader.net.protocol.jar.Handler();
                default -> null;
            });
        } catch (Exception _) {
            Handlers.register();
        }
      }
  
      public BootstrappingGcfLauncher() throws Exception {
          super();
      }
  }

The GcfJarLayoutFactory only places GcfJarLauncher.class at the jar root, so you also need to inject the subclass at the root yourself (the Functions Framework loads the entry-point class from the jar root):

  <plugin>
      <artifactId>maven-antrun-plugin</artifactId>
      <executions>
          <execution>
              <id>inject-bootstrap-launcher</id>
              <phase>package</phase>
              <goals><goal>run</goal></goals>
              <configuration>
                  <target>
                      <!-- keepCompression="true" is critical, see Problem 2 below -->
                      <jar destfile="${project.build.directory}/deploy/${project.build.finalName}.jar"
                           update="true" keepCompression="true">
                          <fileset dir="${project.build.outputDirectory}">
                              <include name="com/example/gcf/BootstrappingGcfLauncher.class"/>
                          </fileset>
                      </jar>
                  </target>
              </configuration>
          </execution>
      </executions>
  </plugin>

We deploy with gcloud and had to set the entry point directly:

gcloud functions deploy ... --entry-point=com.example.gcf.BootstrappingGcfLauncher

2. Ant re-compresses the nested libs and breaks spring boot 4's loader

Spring Boot 4's nested-jar loader requires entries under BOOT-INF/lib/ to be STORED (uncompressed). spring-boot-maven-plugin writes them STORED correctly, but Ant's task rewrites every entry with the default compression (DEFLATED), which produces an java.io.IOException: Nested entry 'BOOT-INF/lib/foo.jar' in container zip '...' must not be compressed-Exception

To fix this we did add keepCompression="true" to the Ant task (already shown above). This preserves the STORED compression on the existing entries while still letting Ant deflate the newly-added launcher class.

What loaderImplementation=CLASSIC does (or doesn't)

We also tried CLASSIC on the spring-boot-maven-plugin — in Spring Boot 4 this configuration parameter no longer exists and is silently ignored. spring boot 4 always uses the new layout with the nested URL protocol.

For us now the function deploys and i hope we can get rid of this workaround soon when this gets fixed. Hope this helps some of you out.

[github-actions]

This issue has been stale for over 60 days