[
https://issues.apache.org/jira/browse/AVRO-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Skraba resolved AVRO-4201.
-------------------------------
Resolution: Duplicate
> hashCode method conflict with schema field result.
> --------------------------------------------------
>
> Key: AVRO-4201
> URL: https://issues.apache.org/jira/browse/AVRO-4201
> Project: Apache Avro
> Issue Type: Bug
> Components: java
> Affects Versions: 1.12.1
> Reporter: Ben Canton
> Priority: Minor
>
> There is a bug in the Avro tools 1.12.1 following this PR
> [https://github.com/apache/avro/pull/1708] when a schema includes a field
> with name {{{}result{}}}.
> In the following example, the schema contains two fields:
> * A field {{result}} of type {{["null", "string"]}}
> * A field {{anotherField}} of type` enum
> The {{hashCode}} method generated based on the {{record.vm}} template will be
> as follow:
> @Overridepublic int hashCode() { int result = 1; result = 31 * result
> + (eventHeader == null ? 0 : eventHeader.hashCode()); result = 31 * result
> + (result == null ? 0 : result.hashCode()); result = 31 * result +
> (anotherField == null ? 0 : ((java.lang.Enum) anotherField).ordinal());
> return result;
> }
>
> Now since the schema has a field {{result}} of type {{["null", "string"]}}
> and the generated {{hashCode}} method declares a {{result}} of type
> {{{}int{}}}. The {{result.hashCode()}} will fail since the local {{result}}
> takes precedence.
> Trying to compile a project using the generated java class throws:
>
> {code:java}
> Compiling with JDK Java compiler API. ..../MyEvent.java:1744: error: bad
> operand types for binary operator '==' result = 31 * result + (result == null
> ? 0 : result.hashCode()); ^ first type: int second type: <null>
> ..../MyEvent.java:1744: error: int cannot be dereferenced result = 31 *
> result + (result == null ? 0 : result.hashCode()); ^ 2 errors > Task
> :compileJava FAILED{code}
>
> For the sake of validating my findings, I have updated my schema and renamed
> my field {{result}} to {{res}} and sure enough that "fixed" the issue.
> Obviously, this is not a solution.
> One workaround would be to use custom Velocity templates, to rename {{int
> result = 1}} to {{int result2 = 1}} (just an example) but that is unpractical
> to maintain.
> It would be great if we could rename the {{result}} in the {{record.vm}}
> template to be something less common.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)