[
https://issues.apache.org/jira/browse/LUCENE-4674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549630#comment-13549630
]
Robert Muir commented on LUCENE-4674:
-------------------------------------
{quote}
"allocating a new byte[] if someOtherStuff offset + length > this.offset +
length?" ?
{quote}
This, preventing a.copy(otherStuff) from overflowing onto b.
I dont want any other functionality in this class. it needs less, not more.
{quote}
Regarding the idea to switch to the java.nio buffers, are there some traps
besides backward compatibility? Should we start migrating our internal APIs to
this API (and maybe even the public ones for 5.0?).
{quote}
I haven't even thought about it really. I actually am less concerned about our
internal apis.
Its the public ones i care about.
I would care a lot less about BytesRef & co if users werent forced to interact
with them.
> Consistently set offset=0 in BytesRef.copyBytes
> -----------------------------------------------
>
> Key: LUCENE-4674
> URL: https://issues.apache.org/jira/browse/LUCENE-4674
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Minor
> Attachments: LUCENE-4674.patch
>
>
> BytesRef.copyBytes(BytesRef other) has two branches:
> - either the destination array is large enough and it will copy bytes after
> offset,
> - or it needs to resize and in that case it will set offset = 0.
> I think this method should always set offset = 0 for consistency, and to
> avoid resizing when other.length is larger than this.bytes.length -
> this.offset but smaller than this.bytes.length.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
