[
https://issues.apache.org/jira/browse/LUCENE-2547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982508#action_12982508
]
Woody Anderson commented on LUCENE-2547:
----------------------------------------
1. true, would you like a null check to throw an NPE? (b/c that's what will
happen anyway... i don't see a lot of 'assert' use in lucene due to java
version issues)
2. also true, though this wouldn't be the first api to accept Long/Integer etc.
that should not be null for the purposes of auto-box behavior
3. what 'internal details' are exposed?
3.a I have no counter argument for "what might happen in 4.0", but i agree that
fieldsData is a weird member of AF; by extension, if fieldsData is set to a
boxed version of the object simply to set it to _something_, why is that? If
the 4.0 you imagine doesn't suffer this need, then whatevs, it's a non-issue.
In the current form, it seems to exist simply for toString() (for human
consumption), stringValue() is what is actually stored in the index, and is
short-lived as you say. fieldsData is not necessarily short lived.
4. depending on your code and how long you keep documents etc. the fieldsData
is not as short lived as the String from stringValue etc. Your point stands
though, I haven't run an isolated profile in this scenario. Creating a field
and setting lots of values isn't a viable test of real behavior though.
Creating documents and adding fields and indexing etc. and depending on the app
there is more going on that would keep fields around longer, which would not
allow the boxed objects to be as optimized as you wish.
At any rate, I understand your points. However, in my application, I already
have Long/Integer and i have to unbox/rebox pointlessly.
I agree that a certain aspect of the issue is addressed by eliminating
fieldsData, and the need for any boxed object to exist. But then you're going
to have the problem of multiple variables or multiple subclasses etc. both of
which seem worse than an Object. This is an object that more than a few users
of the API already have in boxed form, and is not a dominant performance
problem, but I don't think that a method called setLong(Long) confuses very
many people. fwiw, setLong(null) _could_ simply return the field to it's
default state after construction, which isn't the worst thing either (aside
from being impossible with setLong(long)).
It's not a huge issue, but from my perspective, neither is having
setLong(Long), and it's certainly an easy diff for me to splice into my version.
> 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]
