Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to load classes generated by a KSP symbol processor #312

Open
ansman opened this issue Sep 8, 2022 · 11 comments
Open

Unable to load classes generated by a KSP symbol processor #312

ansman opened this issue Sep 8, 2022 · 11 comments

Comments

@ansman
Copy link
Contributor

ansman commented Sep 8, 2022

Here is an example that I use:

val source = kotlin("source.kt", """
    @se.ansman.kotshi.KotshiJsonAdapterFactory
    object Factory : com.squareup.moshi.JsonAdapter.Factory by KotshiFactory
""".trimIndent()
)
val compilation = KotlinCompilation().apply {
  workingDir = temporaryFolder.root
  sources = listOf(source)
  inheritClassPath = true
  messageOutputStream = System.out // see diagnostics in real time
  kspIncremental = true
  symbolProcessorProviders = listOf(KotshiSymbolProcessorProvider())
}
assertThat(result.exitCode).isEqualTo(KotlinCompilation.ExitCode.OK)
val factory = result.classLoader.loadClass("KotshiFactory")
assertThat(factory).isAssignableTo(JsonAdapter.Factory::class.java)

This works fine when using the KAPT version of the processor and I have manually confirmed that the source is indeed generated.

@ansman
Copy link
Contributor Author

ansman commented Sep 9, 2022

This is likely related to all KSP generated files being missing from Result.generatedFiles

@Tiagoperes
Copy link

Tiagoperes commented Oct 28, 2022

This is also happening to me, the file is correctly generated, but the class itself doesn't get loaded into the classpath. Have you find any solution for this @ansman?

@bishiboosh
Copy link
Contributor

What I'm doing right now is doing a second compilation run without processors but including the generated files, but that's only a workaround

@Tiagoperes
Copy link

This is what I just thought of doing. I'll try this and see if it works. Thanks!

@Tiagoperes
Copy link

Compiling the code twice works. Hope we can remove this workaround soon. Thanks for the help!

@bennyhuo
Copy link
Contributor

bennyhuo commented Nov 3, 2022

val compilation = KotlinCompilation().apply {
  ...
  // add this 
  kspWithCompilation = true
}

Ksp won't generate byte code by default. Try enable the compilation with kspWithCompilation option.

@bishiboosh
Copy link
Contributor

@bennyhuo kspWithCompilation does the trick for me, I was able to remove the second round of compilation. Maybe add to the documentation regarding this point ? Otherwise is @ansman is ok I think this issue could be closed

@ansman
Copy link
Contributor Author

ansman commented Nov 4, 2022

I can still not load classes after using kspWithCompilation = true.

Even with this flag set the class loader till only contains the classes dir.
image

@ansman
Copy link
Contributor Author

ansman commented Nov 4, 2022

Ah, it turns it it's likely because I'm generating java sources and not kotlin sources. Perhaps this isn't something that KSP/Compile Testing supports?

@bennyhuo
Copy link
Contributor

bennyhuo commented Nov 5, 2022

/** Performs the 4th compilation step to compile Java source files */
private fun compileJava(sourceFiles: List<File>): ExitCode {
  val javaSources = (sourceFiles + kaptSourceDir.listFilesRecursively())
			  .filterNot<File>(File::hasKotlinFileExtension)

  if(javaSources.isEmpty())
    return ExitCode.OK
  ...
}

Yes, only java sources from sources property and kapt are compiled by Javac.

It is still the best choice to compile again after KSP compilation. And I also did this in my extensions library with module support here kotlin-compile-testing-extensions/KotlinModule

@Tiagoperes
Copy link

kspWithCompilation

This also worked for me! Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants