Running a main() function in IntelliJ fails when the configuration cache is enabled

[TimvdLippe]

Running a main() function in IntelliJ with the configuration cache produces cache failures and fails the build.

Expected Behavior

Executing a main() function in IntelliJ works with the configuration cache.

Current Behavior

Running a main() function in IntelliJ produces the following configuration cache report:

1 problem was found storing the configuration cache.
- Task `:target.main()` of type `org.gradle.api.tasks.JavaExec`: cannot serialize object of type 'java.io.PipedInputStream', a subtype of 'java.io.InputStream', as these are not supported with the configuration cache.
  See https://docs.gradle.org/7.4.2/userguide/configuration_cache.html#config_cache:requirements:disallowed_types

See the complete report at file:///.build/reports/configuration-cache/6q4zhvy8wowwbm62im0lvi12j/fy3ilu2vj9kv4y29vk3oepz3/configuration-cache-report.html

Context

We enabled the configuration cache, but now it breaks when we attempt to run a main() method in IntelliJ.

Steps to Reproduce

1. Enable the configuration cache in your Gradle project
2. Define a class which has a main() method
3. Open IntelliJ and open the class
4. Run the main() class, either by clicking the play button in the bar on the left, or by right-clicking and click "Run main()" in the context menu
5. Your build will now fail with the configuration cache problem.

Your Environment

I wanted to attach the configuration cache report, but since it is a .html file I am unable to. This is the full stacktrace in the report:

⌄⚠️cannot serialize object of type java.io.PipedInputStream📋, a subtype of java.io.InputStream📋, as these are not supported with the configuration cache.[ ?](https://docs.gradle.org/7.4.2/userguide/configuration_cache.html#config_cache:requirements:disallowed_types)
⌄fieldstandardInput📋 of org.gradle.process.internal.ProcessStreamsSpec📋
⌄bean of type org.gradle.process.internal.ProcessStreamsSpec📋
⌄fieldstreamsSpec📋 of org.gradle.process.internal.DefaultJavaExecSpec📋
⌄bean of type org.gradle.process.internal.DefaultJavaExecSpec📋
⌄fieldjavaExecSpec📋 of org.gradle.api.tasks.JavaExec📋
■task:target.main()📋 of type org.gradle.api.tasks.JavaExec📋

[jbartok]

Sorry that you're having trouble with Gradle!

Your issue lacks information about how to reproduce the problem you're having. A reproducer project can really help us track down and fix your problem quicker. We may also be able to suggest workarounds or ways to avoid the problem if we can reproduce it.

You can use the following as a base for your reproducer: https://github.com/gradle/gradle-issue-reproducer

This issue will be closed after 7 days, unless you can provide more information.

[TimvdLippe]

Your issue lacks information about how to reproduce the problem you're having

Unfortunately it's not straightforward for me (legal and stuff) to provide a standalone reproducer project, if the steps are unclear. Please let me know if the steps are sufficient and I can try to get that sorted.

[bamboo]

Hi, @TimvdLippe. Thanks for the report!

This happens because IntelliJ is setting up a JavaExec task to run your class behind the scenes using piped streams which are not supported by the configuration cache.

We are still considering what the best solution for this type of problem might be but, in the meantime, you can mark the offending tasks notCompatibleWithConfigurationCache with something like the following in your build script (assuming Groovy for the example):

tasks.withType(JavaExec).configureEach {
    if (name.endsWith("main()")) {
        notCompatibleWithConfigurationCache("JavaExec created by IntelliJ")
    }
}

[TimvdLippe]

@bamboo Can confirm the workaround fixes it for now, thanks for the suggestion 👍

[ianbrandt]

This seems to no longer be an issue, at least with Gradle 8.7 and IntelliJ 2024.1. Perhaps it was addressed by https://docs.gradle.org/8.7/release-notes.html#supporting-standard-streams-as-task-property-values.

Update: One caveat, I'm still experiencing the bug in IntelliJ 2024.1 where Kotlin main() methods are not run with Gradle: https://youtrack.jetbrains.com/issue/KTIJ-27483/Run-configurations-are-not-picking-app-configuration-from-build.gradle.kts-as-described-in-docs#focus=Comments-27-8378595.0-0. Accordingly, I've only been able to verify that I no longer need the notCompatibleWithConfigurationCache() workaround for Java main() methods launched from IntelliJ, not Kotlin ones.

[bamboo]

Thanks, @ianbrandt! I can confirm that this was indeed fixed in Gradle 8.7.

[mlopatkin]

Indeed, IJ's standard init script for main() is setting up System.in.

standardInput = System.in

I was confused by the PipedInputStream thing, but it comes from Gradle setting up custom System.in implementation.