[
https://issues.apache.org/jira/browse/AVRO-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009212#comment-13009212
]
Doug Cutting commented on AVRO-784:
-----------------------------------
The approach I've heard others mention is, rather than back-compatible, to use
a new set of templates that generates setters and have applications explicitly
upgrade to the new templates. Then the fields could become private and the
generated API would become more abstract, permitting optimizations. But we
could pursue both approaches too.
A few concerns with this patch:
- appending get/set onto the front of field names may result in name
conflicts. For example, a record may have fields named both 'setSize' and
'size'. For other generated names we include a dollar sign, a character that
is not permitted in Avro names. My preference here would be to generate, for a
field named 'foo', a 'foo()' getter and a 'foo(x)' setter.
- we don't need to generate calls to the 'put' and 'get' methods but can
directly set/get the fields.
- if we directly access the fields then we should use javaUnbox instead of
javaType, so that, e.g., the setter for an int field accepts an "int" paramter
rather than an "Integer".
- we should ideally generate javadoc for the setter/getters. if the field in
the schema has documentation then we should include that, otherwise perhaps
generate some vanilla javadoc.
> SpecificCompiler should generate accessors
> ------------------------------------------
>
> Key: AVRO-784
> URL: https://issues.apache.org/jira/browse/AVRO-784
> Project: Avro
> Issue Type: Improvement
> Components: java
> Affects Versions: 1.5.0
> Reporter: E. Sammer
> Labels: features
> Attachments: avro-784.diff
>
>
> Avro's Java SpecificCompiler should generate java bean style accessors.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
