Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Avro, mail # dev - Re: [jira] [Commented] (AVRO-803) Java generated Avro classes make using Avro painful and surprising


Copy link to this message
-
Re: [jira] [Commented] (AVRO-803) Java generated Avro classes make using Avro painful and surprising
Scott Carey 2011-10-12, 03:38


On 10/11/11 10:53 AM, "Doug Cutting" <[EMAIL PROTECTED]> wrote:

>On 10/10/2011 02:51 PM, Scott Carey wrote:
>> Does it work with <stringType>Utf8</stringType> ?  (Sorry, I've been
>> unable to test many patches recently).
>
>Yes.
>
>> I'm not a big fan of what our docs will say:  "never use the default of
>> CharSequence, its broken".  But I can live with that.
>
>It's only as broken as the use of Object in the Map API is broken, and
>as broken as the entire collections API was broken before generics were
>added to Java.  Which is to say, there are bugs that could be caught at
>compile time that will instead only be manifested at runtime.  This is
>not ideal, but neither is it fatal.  It requires that applications
>depend a bit more on good unit tests than just on successful compilation.

Good point, we just need to be clear that map keys as CharSequence can be
dangerous.  Its not an issue at all with every other use case.

>
>Long-term it would certainly be nice to change the default to something
>that better leverages compile time type checking.  But for the 1.6
>release I think it would be a mistake to require application code
>changes.  We just got a bunch of projects to upgrade to 1.5.  It'd be
>really nice if 1.6 could be a drop-in replacement and that we not
>require changes and releases to these projects before any can upgrade.

I agree.   Perhaps later (after 1.6.0) we can add something that makes
code generation use a concrete type for map keys, but still uses
CharSequence for fields or map values.

>
>Doug