[
https://issues.apache.org/jira/browse/LUCENE-2547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982927#action_12982927
]
Simon Willnauer commented on LUCENE-2547:
-----------------------------------------
bq. I didn't dive deep into the details of this issue, but what will someone
who has only long/int (and not their counter objects) do? Will he need to
create a Long/Integer out of them?
Shai, there are primitive setters already though.
bq. The parameters cannot be null, so at least a null-check is missing
agreed
bq. If you try this out with a profiler you see no difference at all (loop
creating a field and setting lots of values) - the objects are shortliving so
JRE optimizes (allocates on thread local heap).
agreed!
I think calling setLong(longRef.longValue()) is not a big deal and an API
change / addition is not needed here. Moving out?
> minimize autoboxing in NumericField
> -----------------------------------
>
> Key: LUCENE-2547
> URL: https://issues.apache.org/jira/browse/LUCENE-2547
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 3.0.2
> Reporter: Woody Anderson
> Assignee: Simon Willnauer
> Fix For: 4.0
>
> Attachments: LUCENE-2547.patch
>
>
> dicIf you already have a Integer/Long/Double etc.
> numericField.setLongValue(long) causes an unnecessary auto-unbox.
> actually, since internal to setLongValue there is:
> {code}
> fieldsData = Long.valueOf(value);
> {code}
> then, there is an explicit box anyway, so this makes setLongValue(Long) with
> an auto-box of long roughly the same as setLongValue(long), but better if you
> started with a Long.
> Long being replaceable with Integer, Float, Double etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
