[
https://issues.apache.org/jira/browse/AVRO-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144219#comment-13144219
]
James Baldassari commented on AVRO-951:
---------------------------------------
>From a design perspective it's better to use method calls rather than directly
>accessing the protected members of a superclass, so I support Doug's approach.
> The only potential drawback is overhead from the extra method invocations.
>Hopefully the Java compiler will inline those calls or use some other
>optimization to prevent any performance impact.
> Records with field named "data" collide with new builder code from specific
> compiler
> ------------------------------------------------------------------------------------
>
> Key: AVRO-951
> URL: https://issues.apache.org/jira/browse/AVRO-951
> Project: Avro
> Issue Type: Bug
> Components: java
> Affects Versions: 1.6.0
> Reporter: Alex Miller
> Assignee: Doug Cutting
> Priority: Blocker
> Fix For: 1.6.1
>
> Attachments: AVRO-951.patch, AVRO-951.patch
>
>
> When I updated my dependencies from 1.5.x to 1.6.0 I found that one of my
> generated specific data classes failed to compile. The schema definition is:
> {code}
> record DataResponse {
> string queryId;
> int startRow;
> boolean more;
> array<array<union {IRI, BNode, PlainLiteral, TypedLiteral,
> string, boolean, int, long, float, double,
> null} >> data;
> }
> {code}
> which I'm using to create:
> {code}
> {
> "type" : "record",
> "name" : "DataResponse",
> "fields" : [ {
> "name" : "queryId",
> "type" : "string"
> }, {
> "name" : "startRow",
> "type" : "int"
> }, {
> "name" : "more",
> "type" : "boolean"
> }, {
> "name" : "data",
> "type" : {
> "type" : "array",
> "items" : {
> "type" : "array",
> "items" : [ "IRI", "BNode", "PlainLiteral", "TypedLiteral",
> "string", "boolean", "int", "long", "float", "double", "null" ]
> }
> }
> }
> {code}
> which generates this code in the specific compiler:
> {code}
> public static class Builder extends
> org.apache.avro.specific.SpecificRecordBuilderBase<DataResponse>
> implements org.apache.avro.data.RecordBuilder<DataResponse> {
> private java.lang.CharSequence queryId;
> private int startRow;
> private boolean more;
> // *** local field named "data"
> private java.util.List<java.util.List<java.lang.Object>> data;
> // snipped some
>
> /** Creates a Builder by copying an existing DataResponse instance */
> private Builder(sherpa.protocol.DataResponse other) {
> super(sherpa.protocol.DataResponse.SCHEMA$);
> if (isValidValue(fields[0], other.queryId)) {
> // *** Call intended to go to super class data field
> queryId = (java.lang.CharSequence) data.deepCopy(fields[0].schema(),
> other.queryId);
> fieldSetFlags[0] = true;
> }
> if (isValidValue(fields[1], other.startRow)) {
> startRow = (java.lang.Integer) data.deepCopy(fields[1].schema(),
> other.startRow);
> fieldSetFlags[1] = true;
> }
> if (isValidValue(fields[2], other.more)) {
> more = (java.lang.Boolean) data.deepCopy(fields[2].schema(),
> other.more);
> fieldSetFlags[2] = true;
> }
> if (isValidValue(fields[3], other.data)) {
> data = (java.util.List<java.util.List<java.lang.Object>>)
> data.deepCopy(fields[3].schema(), other.data);
> fieldSetFlags[3] = true;
> }
> }
> {code}
> If you note the two ***'ed comments above, the first is the locally generated
> "data" field. The second is a reference to a super-class's field, also named
> data (although it's shadowed by the local data field). The super class is
> org.apache.avro.data.RecordBuilderBase.
> Seems like any of the protected fields at that point could potentially
> collide with actual record field names ("schema", "fields", "fieldSetFlags"
> would all have the same problem). Maybe if those fields were accessed via
> getters in the generated code, the local fields could shadow the super class
> without issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
