[GRADLE-3018] The same enum values as task inputs are considered different Created: 10/Feb/14  Updated: 08/Aug/16  Resolved: 25/Jul/16

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 3.0-rc-1

Type: Bug
Reporter: Gradle Forums Assignee: Michael Barnathan (Inactive)
Resolution: Fixed Votes: 3

Issue Links:
Related to GRADLE-2771 Custom types cannot be used as task @... Resolved
Related to GRADLE-3088 Up to date check not working when tas... Resolved


New Gradle Forums Topic: https://discuss.gradle.org/t/two-different-instances-of-the-same-enum-value-for-previous-and-current-input-property-when-using-the-gradle-daemon/1162

The equals() implementation for Enum values is based on object identity. This is problematic when the values of two different instances of the same enum class are tested for equality. This can happen in Gradle when using enum classes from a 3rd party (i.e. non core) and the daemon because of the task artifact cache being held in memory across builds.

Comment by René Gröschke (Inactive) [ 16/Mar/16 ]

handling of enums in non daemon environment needs further investigation.

Comment by Eric Wendelin [ 07/Jul/16 ]

Additional context:
Original problem report against gwt-gradle-plugin: https://github.com/steffenschaefer/gwt-gradle-plugin/issues/18

At least one root problem we're encountering here is that Gradle will create a new ClassLoader when a build script is changed and we currently cannot compare non-primitive values that aren't files because Objects from different ClassLoaders cannot be equal.
I have developed an example project to reproduce the issue: https://github.com/eriwen/gradle-3-0-testing/tree/master/gwt

One very slow solution would be to serialize both Enum values.

According to my testing with the example project and tests defined in InMemoryTaskArtifactsIntegrationTest, this is not a daemon-specific issue.

Generated at Wed Jun 30 12:37:40 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.