Spring Boot 3 Native Fails to Start with Kotlin @JvmStatic Main Method

[akefirad]

Bug Report for Spring Boot 3 Native (GraalVM 22.3)
Having a simple Spring Boot application (generated on start.spring.io), changing the main class to:

@SpringBootApplication(proxyBeanMethods = false)
class DemoApplication {
  companion object {
    @JvmStatic
    fun main(args: Array<String>) {
      runApplication<DemoApplication>(*args)
    }
  }
}

And building the native image (via ./gradlew nativeCompile) gives you an executable that fails to start with:

2022-10-29T11:11:27.459+02:00 ERROR 8553 --- [           main] o.s.boot.SpringApplication               : Application run failed

java.lang.IllegalArgumentException: Could not find class [com.example.demo.DemoApplication$Companion__ApplicationContextInitializer]
        at org.springframework.util.ClassUtils.resolveClassName(ClassUtils.java:333) ~[na:na]
        at org.springframework.context.aot.AotApplicationContextInitializer.instantiateInitializer(AotApplicationContextInitializer.java:80) ~[demo:6.0.0-RC2]
        at org.springframework.context.aot.AotApplicationContextInitializer.initialize(AotApplicationContextInitializer.java:71) ~[demo:6.0.0-RC2]
        at org.springframework.context.aot.AotApplicationContextInitializer.lambda$forInitializerClasses$0(AotApplicationContextInitializer.java:61) ~[demo:6.0.0-RC2]
        at org.springframework.boot.SpringApplication.applyInitializers(SpringApplication.java:603) ~[demo:3.0.0-RC1]
        at org.springframework.boot.SpringApplication.prepareContext(SpringApplication.java:383) ~[demo:3.0.0-RC1]
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:307) ~[demo:3.0.0-RC1]
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1302) ~[demo:3.0.0-RC1]
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1291) ~[demo:3.0.0-RC1]
        at com.example.demo.DemoApplication$Companion.main(DemoApplication.kt:15) ~[na:na]
        at com.example.demo.DemoApplication.main(DemoApplication.kt) ~[demo:na]
Caused by: java.lang.ClassNotFoundException: com.example.demo.DemoApplication$Companion__ApplicationContextInitializer
        at java.base@19.0.1/java.lang.Class.forName(DynamicHub.java:1132) ~[demo:na]
        at org.springframework.util.ClassUtils.forName(ClassUtils.java:283) ~[na:na]
        at org.springframework.util.ClassUtils.resolveClassName(ClassUtils.java:323) ~[na:na]
        ... 10 common frames omitted

Let me know if you need more information. Thanks.

[mhalbritter]

Looks like we deduce the wrong class name for the application context initializer: com.example.demo.DemoApplication$Companion__ApplicationContextInitializer because of the Kotlin Companion Object. The generated initializer is called DemoApplication__ApplicationContextInitializer.

Workaround until fixed:

@SpringBootApplication
class DemoApplication

fun main(args: Array<String>) {
	runApplication<DemoApplication>(*args)
}

which is the default code the initializer generates.

[akefirad]

You're right. The workaround doesn't work for me since I have to set the main class in bootRun task in build.gradle, unless there's a way to set the main class in the task when the main method is a free one.

[mhalbritter]

There is. The default class name for free functions is the filename + "Kt", so in your case DemoApplicationKt:

springBoot {
	mainClass.set("com.example.demo.DemoApplicationKt")
}

You can rename the class by using

@file:JvmName("SomeOtherClassName")

springBoot {
	mainClass.set("com.example.demo.SomeOtherClassName")
}

See here: https://kotlinlang.org/docs/java-to-kotlin-interop.html#package-level-functions

[akefirad]

Got it. Thanks for the link. 🙏

[wilkinsona]

The workaround doesn't work for me since I have to set the main class in bootRun task

This shouldn't be necessary. bootRun should be automatically configured to use the right main class when using either a companion object or a package-level function.

[wilkinsona]

I wonder if we should set the main class in the Kotlin extension. Things are a little odd at the moment, even without AOT, as the companion object's class is used for logging:

2022-11-03T19:46:16.594Z  INFO 33846 --- [           main] e.k.KotlinMainClassApplication$Companion : Starting KotlinMainClassApplication.Companion using Java 17.0.5 with PID 33846 (/Users/awilkinson/dev/temp/kotlin-main-class/build/classes/kotlin/main started by awilkinson in /Users/awilkinson/dev/temp/kotlin-main-class)

If we set the main class, it looks like this instead:

2022-11-03T19:48:04.743Z  INFO 35059 --- [           main] c.e.k.KotlinMainClassApplication         : Starting KotlinMainClassApplication using Java 17.0.5 with PID 35059 (/Users/awilkinson/dev/temp/kotlin-main-class/build/classes/kotlin/main started by awilkinson in /Users/awilkinson/dev/temp/kotlin-main-class)

That's after making these changes to the extensions:

diff --git a/spring-boot-project/spring-boot/src/main/kotlin/org/springframework/boot/SpringApplicationExtensions.kt b/spring-boot-project/spring-boot/src/main/kotlin/org/springframework/boot/SpringApplicationExtensions.kt
index 8a1269d06b..3ae3cdbc6c 100644
--- a/spring-boot-project/spring-boot/src/main/kotlin/org/springframework/boot/SpringApplicationExtensions.kt
+++ b/spring-boot-project/spring-boot/src/main/kotlin/org/springframework/boot/SpringApplicationExtensions.kt
@@ -1,5 +1,5 @@
 /*
- * Copyright 2012-2017 the original author or authors.
+ * Copyright 2012-2022 the original author or authors.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -26,8 +26,12 @@ import org.springframework.context.ConfigurableApplicationContext
  * @author Sebastien Deleuze
  * @since 2.0.0
  */
-inline fun <reified T : Any> runApplication(vararg args: String): ConfigurableApplicationContext =
-               SpringApplication.run(T::class.java, *args)
+inline fun <reified T : Any> runApplication(vararg args: String): ConfigurableApplicationContext {
+       val application = SpringApplication(T::class.java)
+       application.setMainApplicationClass(T::class.java)
+       return application.run(*args)
+}
+
 
 /**
  * Top level function acting as a Kotlin shortcut allowing to write
@@ -38,5 +42,8 @@ inline fun <reified T : Any> runApplication(vararg args: String): ConfigurableAp
  * @author Sebastien Deleuze
  * @since 2.0.0
  */
-inline fun <reified T : Any> runApplication(vararg args: String, init: SpringApplication.() -> Unit): ConfigurableApplicationContext =
-               SpringApplication(T::class.java).apply(init).run(*args)
+inline fun <reified T : Any> runApplication(vararg args: String, init: SpringApplication.() -> Unit): ConfigurableApplicationContext {
+       val application = SpringApplication(T::class.java).apply(init)
+       application.setMainApplicationClass(T::class.java)
+       return application.run(*args)
+}

WDYT, @sdeleuze, does this make sense?

[wilkinsona]

Looking more closely, I think this is a bug in the code where we deduce the main application class. It can effect Java too if you write some (convoluted) code that has a similar structure to the code the Kotlin's compiler generates:

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class DemoApplication {

	public static void main(String[] args) {
		Companion.main(args);
	}
	
	static class Companion {
		
		static void main(String[] args) {
			SpringApplication.run(DemoApplication.class, args);			
		}

	}

}

SpringApplicaton will deduce the main class to be DemoApplication$Companion but the MainClassFinder that's used by our Maven and Gradle plugins will correctly identify that it's DemoApplication.

At the moment we identify the main class by walking the stack and finding the first frame for a method named main. In the example above, we really need to look for the last frame. However, by doing that we risk picking up another main method that's then called the application's main method to start it. @SpringBootTests configured to use the main method would be affected by this were it not for the fact that they explicitly set the main application class.

We can't narrow things down by looking for a particular type of method as it doesn't work with Graal. For the reasons above, I'm also not sure that we can safely look for the last method named main rather than the first. I'm back to thinking that a Kotlin-specific fix may be our best option.

[wilkinsona]

Here's a change that corrects the main class only when a companion object is used:

diff --git a/spring-boot-project/spring-boot/src/main/kotlin/org/springframework/boot/SpringApplicationExtensions.kt b/spring-boot-project/spring-boot/src/main/kotlin/org/springframework/boot/SpringApplicationExtensions.kt
index 8a1269d06b..2405a00f2e 100644
--- a/spring-boot-project/spring-boot/src/main/kotlin/org/springframework/boot/SpringApplicationExtensions.kt
+++ b/spring-boot-project/spring-boot/src/main/kotlin/org/springframework/boot/SpringApplicationExtensions.kt
@@ -1,5 +1,5 @@
 /*
- * Copyright 2012-2017 the original author or authors.
+ * Copyright 2012-2022 the original author or authors.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -26,8 +26,15 @@ import org.springframework.context.ConfigurableApplicationContext
  * @author Sebastien Deleuze
  * @since 2.0.0
  */
-inline fun <reified T : Any> runApplication(vararg args: String): ConfigurableApplicationContext =
-               SpringApplication.run(T::class.java, *args)
+inline fun <reified T : Any> runApplication(vararg args: String): ConfigurableApplicationContext {
+       val application = SpringApplication(T::class.java)
+       val possibleCompanionClass = object{}.javaClass.enclosingClass
+       if (possibleCompanionClass.enclosingClass != null && possibleCompanionClass.kotlin.isCompanion) {
+               application.setMainApplicationClass(possibleCompanionClass.enclosingClass)
+       }
+       return application.run(*args)
+}
+
 
 /**
  * Top level function acting as a Kotlin shortcut allowing to write
@@ -38,5 +45,11 @@ inline fun <reified T : Any> runApplication(vararg args: String): ConfigurableAp
  * @author Sebastien Deleuze
  * @since 2.0.0
  */
-inline fun <reified T : Any> runApplication(vararg args: String, init: SpringApplication.() -> Unit): ConfigurableApplicationContext =
-               SpringApplication(T::class.java).apply(init).run(*args)
+inline fun <reified T : Any> runApplication(vararg args: String, init: SpringApplication.() -> Unit): ConfigurableApplicationContext {
+       val application = SpringApplication(T::class.java).apply(init)
+       val possibleCompanionClass = object{}.javaClass.enclosingClass
+       if (possibleCompanionClass.enclosingClass != null && possibleCompanionClass.kotlin.isCompanion) {
+               application.setMainApplicationClass(possibleCompanionClass.enclosingClass)
+       }
+       return application.run(*args)
+}

It's pretty gross. It's using an anonymous inner class (object{}) and then getting the enclosing class to identify the class into which the function has been inlined. We can then check if it's a companion class and set the main application class if it is.