Quarkus dev mode does not honor Kotlin compiler args

[mbleichner]

Describe the bug

On initial compile, Kotlin compiler args get applied, but as soon as Quarkus triggers a recompilation in dev mode, they don't seem to be applied anymore.

Expected behavior

Kotlin compiler args should always be applied.

Actual behavior

Kotlin compiler args only get applied on first compile.

How to Reproduce?

1. code-with-quarkus.zip
2. ./mvnw quarkus:dev
3. http://localhost:8080/graphql/schema.graphql

"Query root"
type Query {
  bananas: [Banana!]!
}

4. Make a change in GraphQLResource.kt (e.g. uncomment line 10)
5. http://localhost:8080/graphql/schema.graphql

"Query root"
type Query {
  bananas: [Banana]!
}

6. Notice how one of the exclamation marks is gone after recompiling.

Output of uname -a or ver

Linux 5.13.0-28-generic

Output of java -version

Java 11

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.7.1.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Maven

Additional information

I'm using Smallrye GraphQL as an example here, but the problem is probably not related to it.

Smallrye GraphQL uses annotations to determine Nullability: List<@NonNull Banana>

For this to work, the following compiler arg has to be set:

<args>
  <arg>-Xemit-jvm-type-annotations</arg>
</args>

This settings seems to get eaten by the dev mode recompilation.

[quarkus-bot[bot]]

/cc @evanchooly

[mschorsch]

@evanchooly This also happens with quarkus-rest-client-reactive. If i use the kotlin compiler option <arg>-Xjvm-default=all</arg> the rest client crashes on recompile (dev mode only). This issue seems a general problem in dev mode with additional compiler args for kotlin in quarkus.

/cc @geoand

[geoand]

@glefloch I think we have some support for this, no?

[glefloch]

Yes I thought too. But looking at https://github.com/quarkusio/quarkus/blob/main/extensions/kotlin/deployment/src/main/java/io/quarkus/kotlin/deployment/KotlinCompilationProvider.java We only set compiler plugin arguments and not compiler arguments anymore. I think this comes from the fact that those arguments can be mixed with java compiler arguments as we collect all arguments in one list.

I don't know what is the best strategy here, should we try to set compiler arguments and warn the user in case of error?

[geoand]

Yes I thought too. But looking at https://github.com/quarkusio/quarkus/blob/main/extensions/kotlin/deployment/src/main/java/io/quarkus/kotlin/deployment/KotlinCompilationProvider.java We only set compiler plugin arguments and not compiler arguments anymore. I think this comes from the fact that those arguments can be mixed with java compiler arguments as we collect all arguments in one list.

Interesting...

I don't know what is the best strategy here, should we try to set compiler arguments and warn the user in case of error?

Wouldn't it make sense to only the Kotlin compiler arguments and not the Java compiler arguments at all?

[glefloch]

All compiler arguments are set in a single list. This list is used to build the devmode launcher. In the launcher, all compilation providers are loaded through SPI. The list of compiler options is used to build a context.

However, it looks like there is compiler specific context. We could set different option based on the compiler. I will give it a try

[mschorsch]

@glefloch Is there any progress on this issue?

[mschorsch]

@geoand @glefloch In Kotlin it is not uncommon to set additional compiler options. These options are currently not properly considered and lead to crashes (https://github.com/quarkusio/quarkus/issues/23780#issuecomment-1042762926) or surprising (https://github.com/quarkusio/quarkus/issues/23780#issue-1141038280) behavior when reloading in dev mode.

Can anyone take a look at this issue?

[glefloch]

There is an older issue that track this issue too. This got out of my todo list. Last week I started working on the introduction of a new property for the dev task that will contains kotlin specific compiler arguments.

[geoand]

@FroMage have your changes since fixed this?

[FroMage]

No, my fixes were related to annotation processors, not this area at all. But it should not be hard to fix, if anyone here wants to try a PR, we can help :)