Moshi kapt deprecation warning always shown?

[G00fY2]

Does the deprecation warning about kapt is always shown, regardless of Moshi already being used with ksp?

moshi/moshi-kotlin-codegen/src/main/java/com/squareup/moshi/kotlin/codegen/apt/JsonClassCodegenProcessor.kt

Line 73 in 491e66b

processingEnv.messager.printMessage(Diagnostic.Kind.WARNING, "Kapt support in Moshi Kotlin Code Gen is deprecated and will be removed in 2.0. Please migrate to KSP. https://github.com/square/moshi#codegen")

[ZacSweers]

If it's being shown, it means Moshi is being loaded into kapt/apt and you should remove it from that configuration.

[ZacSweers]

This is a hilt bug, it's loading all annotation processors for some reason in the :app:hiltJavaCompileDebug task. Looks like it's capturing all KSP and kapt dependencies and passing them on to the JavaCompile task it creates

[G00fY2]

I created google/dagger#4116. Let's see what the dagger team says.

[mkubiczek]

How to suppress this warning when -Werror compiler flag is used?

[G00fY2]

From my perspective the easiest solution would be changing moshis warning messages, as suggested by the hilt team.

Not sure how the Moshi maintainers feel about it? Maybe it's worth creating an issue and/or a PR to address this?

Moshi could change the location where the message is reported such that only if it really needs to do processing then (i.e. in a round) it reports the warning and not when it is loaded. This is up to the Moshi authors to decide if it is possible and still maintains their desired migration to KSP goals.

[ZacSweers]

Hilt is loading KSP dependencies into an APT classpath. Tbh I don't see why annotation processor maintainers need to do something to work around hilt's behavior

[jdelga]

It has been more than one year with this annoying noisy warning although kapt is not used in the project.

Is there any update on a 2.0 version?

[ZacSweers]

And for over a year it's been a hilt bug: #1752 (reply in thread). Coming here to whine about something you could ultimately resolve for yourself a number of ways is unconstructive.

[jdelga]

The message actually reads Kapt support in Moshi Kotlin Code Gen is deprecated and will be removed in 2.0

I am just asking if there is such version 2.0 in the near future.

Thanks.

[TWiStErRob]

Anyone who watches: KAPT code has been removed in #1848 in 2024 June, and that's released in 2.0.0-alpha.1 2026 January.

[muzso]

Coming here to whine about something you could ultimately resolve for yourself a number of ways is unconstructive.

Can you give us a couple of hints on how we can resolve this for ourselves? I'm new both to Moshi and Hilt. I've tried to google the solution, which led me here.

So far it seems to me that one the following has to happen:

• wait for a patch from Hilt
• wait for Moshi 2.* to be released
• fork either Moshi or Hilt and fix the issue ourselves (submitting a PR seems illogical since maintainers of both projects consider the issue to be with the other project)

The first two might happen at some point in the future (they don't resolve the warning for an indefinite amount of time), the third is not really an option (the effort of maintaining a locally patched version of either of these two projects would outweigh the benefits of getting rid of the given warning).

[muzso]

I googled a bit more (read a number of GH issues and their comments, a number of StackOverflow questions, etc.), but still no solution/workaround in sight.

Eventually I settled with asking ChatGPT (since I'm not an Android programmer, it was unlikely that I'd just find a solution by myself within reasonable time) and with a bit of back and forth we got to a solution. From what I can tell, it's exactly the kind of solution that @ZacSweers was referring to. I.e. removing Moshi from Hilt's (i.e. the hiltJavaCompileDebug task's) classpath.

I've added the following to the end of my app/build.gradle.kts and the warning is gone:

tasks.withType<JavaCompile>().configureEach {
  if (name.startsWith("hiltJavaCompile")) {
    doFirst {
      options.annotationProcessorPath =
        options.annotationProcessorPath?.filter {
          !it.name.startsWith("moshi-kotlin-codegen-")
        }
    }
  }
}

(Note: you'll need an import org.gradle.api.tasks.compile.JavaCompile too, preferably at the start of the file)

As stated before: I'm not an Android developer. I had no idea why the "doFirst { ... }" is required, but I've tried it without doFirst and options.annotationProcessorPath seems to be null and the Moshi warning remains.

Asked ChatGPT about it and got the following reason: "It's required here because Hilt doesn't populate hiltJavaCompileDebug's annotationProcessorPath until later in the build lifecycle."

So that's the full explanation to newbies like me.