[
https://issues.apache.org/jira/browse/AVRO-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting updated AVRO-249:
------------------------------
Attachment: AVRO-249.patch
> BigEndian, it appears. Does that fact belong in documentation for the Reflect
> API?
Yes. I added this to ReflectData, along with the documentation of other
mappings.
> On reading, it will be a bit faster if you avoid the array allocation
At this point I am not concerned about performance here. The reflect API
already suffers from known performance problems. The correct handling of
shorts is required for reflection to support existing Hadoop RPC protocols, a
primary target for the reflect API. If this does show up as a performance
bottleneck in benchmarks then we should address it.
> Just to confirm, the "fixed" type doesn't store a length byte, so there is no
> extra overhead.
That's correct.
> What about char? Its just an unsigned short.
If we need, we could add support for that in a separate issue.
> in reflection, represent Java short as fixed data
> -------------------------------------------------
>
> Key: AVRO-249
> URL: https://issues.apache.org/jira/browse/AVRO-249
> Project: Avro
> Issue Type: Improvement
> Components: java
> Reporter: Doug Cutting
> Assignee: Doug Cutting
> Fix For: 1.3.0
>
> Attachments: AVRO-249.patch, AVRO-249.patch
>
>
> Currently the Java reflect API treats shorts as ints. This fails however to
> naturally handle shorts in arrays and other containers. It would be better
> if we used a distinct type for reflected Java short values.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
