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' setter.
The prepending, in the case of similarly named fields, would simply result in 'setSetSize(sizeSize)' which would probably be as the user intended. This should be fine.
The rationale for adhering to the javabean style accessors is that many frameworks and libraries already grok these names during reflection. For instance, Spring takes advantage of this for automatic resolution of names of properties all over the place.
Would you be willing to accept these conventions? Also, if you don't think this makes sense, would it be acceptable to create an annotation / json property that results in generated accessor so users have the choice? i.e.
@get @set int foo;
we don't need to generate calls to the 'put' and 'get' methods but can directly set/get the fields.
Wasn't sure if that was OK. Sounds good.
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.