[
https://issues.apache.org/jira/browse/AVRO-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019525#comment-13019525
]
Scott Carey commented on AVRO-803:
----------------------------------
A co-worker highlighted this and brought this to my attention very recently.
CharSequence's contract explicity states that hashCode() and equals() are not
consistent across implementations.
http://download.oracle.com/javase/6/docs/api/java/lang/CharSequence.html
And thus a CharSequence can't be used for a key in a map.
In Java, we'll have to use a specific implementation of CharSequence inside any
map keys, and can't generalize on CharSequence in a few places. The low level
Encoder / Decoder can happily use CharSequence in many places, but generated
classes and interfaces on the higher layer APIs have to be more strict.
> Java generated Avro classes make using Avro painful and surprising
> ------------------------------------------------------------------
>
> Key: AVRO-803
> URL: https://issues.apache.org/jira/browse/AVRO-803
> Project: Avro
> Issue Type: Improvement
> Components: java
> Affects Versions: 1.5.0
> Environment: Any
> Reporter: Sam Pullara
> Fix For: 1.5.1
>
>
> Currently the Avro generated Java classes expose CharSequence in their API.
> However, you cannot use any old CharSequence when interacting with them. In
> fact, you have to use the Utf8 class if you want to get consistent results. I
> think that Avro should work with any CharSequence if that is the API. Here is
> an example where this happens:
> https://github.com/spullara/avro-generated-code/blob/master/src/test/java/AnnoyingTest.java
> That prints out 'false' three times unexpectedly. If you can't get it to
> print 'true' three times then you should probably change it back to Utf8.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
