[
https://issues.apache.org/jira/browse/AVRO-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009239#comment-13009239
]
Scott Carey commented on AVRO-784:
----------------------------------
In the long run we'll end up with a few variations for generated code. One of
them will nee to be 'standard' bean compatible, with set/get prefixes because
other frameworks look for that.
In general, the user should have a choice on how to generate the access
methods. However, the first iteration does not need to be that flexible, as
long as it doesn't cause difficulty implementing other variations in the future.
The signature for a nullable type would differ from a non-nullable type if they
both are not objects, for example:
{code}
Integer getFooCount();
void setFooCount(Integer fooCount);
{code}
for nullable types and
{code}
int getFooCount();
void setFooCount(int fooCount);
{code}
for non-nullable types.
Other likely variations that others may contribute later:
* getters without setters, using an immutable object + builder pattern.
* nullable intrinsics not boxed, but using a BitSet or similar to check for
null (minimize memory footprint).
Do we want to simply mark the whole record with an annotation (@bean,
@immutable, @builder)? Or do we need the flexibility at the field level?
> 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
