Yes, and it is also required to make it a valid map to begin with. CharSequence's contract does not define hashCode and equals(), so a map that does not contain uniformly typed keys is broken.
The issue is tracked here: https://issues.apache.org/jira/browse/AVRO-803 I do not believe anyone is currently working on it. Most solutions would be API changes and can't be in a patch release. The Java code generation in Avro is done with templates, and one can use a different template to change the generated class output as a work-around. On 5/6/11 9:44 AM, "Alex Miller" <[email protected]> wrote: >Hi, I've been dipping my toe in using Avro and I had a question about >the compiler-generated Java classes. > >I notice that something like > >{"name": "Request", > "type": "record", > "fields": [{"name": "params", "type": {"type":"map", "values": >"string"}}]} > >will generate a Request.java with a field like: > Map<CharSequence,CharSequence> params; > >which is annoying in many common uses of this class. For example this >code won't compile: > Map<String,String> map = ... something I got from somewhere else... > request.params = map; // compile error > >This could be avoided by instead declaring the type of params as: > Map<? extends CharSequence, ? extends CharSequence> params; > >and I think is more accurate. It looks like this is a straightforward >change in SpecificCompiler.javaType(). If this seems desirable, I'll >log a bug and submit a patch.
