Since JavaExec and Exec tasks do not declare any outputs (with @OutputFile, @OutputDirectory, etc), tasks of this type will never be up-to-date.

If build author creates a JavaExec/Exec task and adds outputs themselves (outputs.file ...), some surprising behavior can occur.

Situation 1:
1. Exec task declares output
2. Build author mistakenly passes the wrong arguments to the executable (e.g., output goes to the "wrong" place or the script fails without a failing exit code).
3. Build is executed. Mistake is found.
4. Build author fixes Exec task's args.
5. Build is executed, but Exec task is up-to-date.

Situation 2:
1. Exec task declares output and inputs.
2. Build author does not set the working directory. The executable implicitly looks for files with a particular extension in the working directory.
3. Build is executed. Output is "missing" because no input files were found.
4. Build author fixes Exec task's working directory.
5. Build is executed, but Exec task is up-to-date.

Situation 3:
1. Exec task declares output.
2. Build author mistakenly uses the wrong executable due to copy and paste.
3. Build is executed. Output is "missing" because the executable accepts the same sort of arguments, but produces different output.
4. Build author changes Exec task's executable.
5. Build is executed, but Exec task is up-to-date.

JavaExec has a similar set of situations (or more if we consider system properties and JVM args too).

This is an annoyance when developing build scripts/plugins, but this can really cause a lack of trust with build users if a mistake like any of the above make it to them. They would need to re-run the build with --rerun-tasks or locally change the task in a way that Gradle will notice. This problem also cuts across our general advice to always declare inputs and outputs for a task.

The workaround is to use a custom task that wraps project.exec or extends JavaExec/Exec with the appropriate annotations. Or to manually add the command-line, executable and working directory as an input (inputs.property ...). A custom task is usually better in this case since build users won't have to worry about the exact command-line to pass to executables.

If we were to consider workingDir, executable and args as @Inputs, we could potentially cause existing builds to execute more often than they do today. I think in most cases, this would be the expected behavior and the task would have been considered broken before. There may be cases where the order of the arguments are not important (and possibly change between builds). For tasks like that, the build author could impose an ordering to keep the list of arguments stable.