While I agree that those are all important problems, I think my suggestion is a much smaller tweak (which avoids trying to do anything about the bigger issues).
If you'd rather address it comprehensively, I understand that too. I sense there is a history here around how to represent strings and leverage UTF-8 but I'm not familiar with it. Can you shed any light? > ---------- Forwarded message ---------- > From: Scott Carey <[email protected]> > To: "[email protected]" <[email protected]> > Date: Fri, 6 May 2011 10:14:16 -0700 > Subject: Re: Generics question on compiler-generated Java classes > 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. > > > >
