# Java-api: SearchHitField usage

**URL:** <https://discuss.elastic.co/t/java-api-searchhitfield-usage/4083>\
**Category:** Elasticsearch\
**Created:** [March 11, 2011, 3:09pm UTC](https://discuss.elastic.co/t/java-api-searchhitfield-usage/4083 "2011-03-11T15:09:20Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![K\_B](https://avatars.discourse-cdn.com/v4/letter/k/278dde/32.png) [@K\_B](https://discuss.elastic.co/u/K_B)\
**Post date:** [March 11, 2011, 3:09pm UTC](https://discuss.elastic.co/t/java-api-searchhitfield-usage/4083/1 "2011-03-11T15:09:20Z")

</div>

Hello,

when I get back a SearchHit hit, I can get back the fields with  
hit.getFields();

This leads to a Map\<String, SearchHitField\> where String is the name  
of the field and SearchHitField actually is an Interface just having:

String name();  
Object value();  
List values();

(plus getters with get..);

Actually is there a special reason there is no Map\<String, String\>  
hit.getSimpleFields(); or sth. like that in it as I don\*t see the  
reason to get back a map of Objects that contains the key as String  
name plus and Object Value that is the content of the field (the idea  
with List seems bit strange to me - either I get back an  
Object thst is instance of List or not - but a List is actually an  
Object when it exists as List itself is just a specialized interface  
derived from Collection - so, this is not good in terms of OO imho);

Best

---

<div class="post-metadata">

**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\
**Post date:** [March 12, 2011, 7:13am UTC](https://discuss.elastic.co/t/java-api-searchhitfield-usage/4083/2 "2011-03-12T07:13:44Z")

</div>

A field, when stored / executed as a script, can be retrieved, and when fetched, it can be of different types (numeric, string, and so on). Thats the reason why the type if Object, if you want the String representation, you can call toString on it.

The reason why it has both value() and values() is because a field can have several values for it indexed (for example, an array of values). So, when stored, you can get the list of values associated with it (in which case, the value method will just return the first one). The reason its a List is because it maintains the order of the values indexed.  
On Friday, March 11, 2011 at 5:09 PM, K.B. wrote:  
Hello,

> when I get back a SearchHit hit, I can get back the fields with  
> hit.getFields();
> 
> This leads to a Map\<String, SearchHitField\> where String is the name  
> of the field and SearchHitField actually is an Interface just having:
> 
> String name();  
> Object value();  
> List values();
> 
> (plus getters with get..);
> 
> Actually is there a special reason there is no Map\<String, String\>  
> hit.getSimpleFields(); or sth. like that in it as I don\*t see the  
> reason to get back a map of Objects that contains the key as String  
> name plus and Object Value that is the content of the field (the idea  
> with List seems bit strange to me - either I get back an  
> Object thst is instance of List or not - but a List is actually an  
> Object when it exists as List itself is just a specialized interface  
> derived from Collection - so, this is not good in terms of OO imho);
> 
> Best

---

<div class="post-metadata">

**Author:** ![K\_B](https://avatars.discourse-cdn.com/v4/letter/k/278dde/32.png) [@K\_B](https://discuss.elastic.co/u/K_B)\
**Post date:** [March 12, 2011, 5:09pm UTC](https://discuss.elastic.co/t/java-api-searchhitfield-usage/4083/3 "2011-03-12T17:09:45Z")

</div>

Hey Shay,

I understand but as a Java programmer, I still feel uncomfortable:  
getting back a List is ok as well as an Object, but those together is  
not good; Reason is simply any List is also an object, so to be it  
correctly it's just:

String name;  
Object value;

and in case you get back many objects the value is an Object of  
interface type List, meaning a single List object 🙂

Also in runtime its not sure if you will get back a single object or a  
list (remember, we have no schema usually), so you need to care anyway  
with the danger of getting an Object holding other object's in it;

Following that, the logical consequence for regular SearchHit's is to  
strip the class as same behaviour can be achived by giving back a  
Map\<String, Object\>;

Best

On 12 Mrz., 08:13, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:

> A field, when stored / executed as a script, can be retrieved, and when fetched, it can be of different types (numeric, string, and so on). Thats the reason why the type if Object, if you want the String representation, you can call toString on it.
> 
> The reason why it has both value() and values() is because a field can have several values for it indexed (for example, an array of values). So, when stored, you can get the list of values associated with it (in which case, the value method will just return the first one). The reason its a List is because it maintains the order of the values indexed.On Friday, March 11, 2011 at 5:09 PM, K.B. wrote:
> 
> Hello,
> 
> > when I get back a SearchHit hit, I can get back the fields with  
> > hit.getFields();
> 
> > This leads to a Map\<String, SearchHitField\> where String is the name  
> > of the field and SearchHitField actually is an Interface just having:
> 
> > String name();  
> > Object value();  
> > List values();
> 
> > (plus getters with get..);
> 
> > Actually is there a special reason there is no Map\<String, String\>  
> > hit.getSimpleFields(); or sth. like that in it as I don\*t see the  
> > reason to get back a map of Objects that contains the key as String  
> > name plus and Object Value that is the content of the field (the idea  
> > with List seems bit strange to me - either I get back an  
> > Object thst is instance of List or not - but a List is actually an  
> > Object when it exists as List itself is just a specialized interface  
> > derived from Collection - so, this is not good in terms of OO imho);
> 
> > Best

---

<div class="post-metadata">

**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\
**Post date:** [March 12, 2011, 5:38pm UTC](https://discuss.elastic.co/t/java-api-searchhitfield-usage/4083/4 "2011-03-12T17:38:21Z")

</div>

You can treat the value method as a helper to get the first object in the list if the list is not empty. Otherwise, you can just use the values method that returns a List of objects if thats how you like it.  
On Saturday, March 12, 2011 at 7:09 PM, K.B. wrote:

> Hey Shay,
> 
> I understand but as a Java programmer, I still feel uncomfortable:  
> getting back a List is ok as well as an Object, but those together is  
> not good; Reason is simply any List is also an object, so to be it  
> correctly it's just:
> 
> String name;  
> Object value;
> 
> and in case you get back many objects the value is an Object of  
> interface type List, meaning a single List object 🙂
> 
> Also in runtime its not sure if you will get back a single object or a  
> list (remember, we have no schema usually), so you need to care anyway  
> with the danger of getting an Object holding other object's in it;
> 
> Following that, the logical consequence for regular SearchHit's is to  
> strip the class as same behaviour can be achived by giving back a  
> Map\<String, Object\>;
> 
> Best
> 
> On 12 Mrz., 08:13, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> 
> > A field, when stored / executed as a script, can be retrieved, and when fetched, it can be of different types (numeric, string, and so on). Thats the reason why the type if Object, if you want the String representation, you can call toString on it.
> > 
> > The reason why it has both value() and values() is because a field can have several values for it indexed (for example, an array of values). So, when stored, you can get the list of values associated with it (in which case, the value method will just return the first one). The reason its a List is because it maintains the order of the values indexed.On Friday, March 11, 2011 at 5:09 PM, K.B. wrote:
> > 
> > Hello,
> > 
> > > when I get back a SearchHit hit, I can get back the fields with  
> > > hit.getFields();
> > 
> > > This leads to a Map\<String, SearchHitField\> where String is the name  
> > > of the field and SearchHitField actually is an Interface just having:
> > 
> > > String name();  
> > > Object value();  
> > > List values();
> > 
> > > (plus getters with get..);
> > 
> > > Actually is there a special reason there is no Map\<String, String\>  
> > > hit.getSimpleFields(); or sth. like that in it as I don\*t see the  
> > > reason to get back a map of Objects that contains the key as String  
> > > name plus and Object Value that is the content of the field (the idea  
> > > with List seems bit strange to me - either I get back an  
> > > Object thst is instance of List or not - but a List is actually an  
> > > Object when it exists as List itself is just a specialized interface  
> > > derived from Collection - so, this is not good in terms of OO imho);
> > 
> > > Best

---

<div class="post-metadata">

**Author:** ![K\_B](https://avatars.discourse-cdn.com/v4/letter/k/278dde/32.png) [@K\_B](https://discuss.elastic.co/u/K_B)\
**Post date:** [March 12, 2011, 6:56pm UTC](https://discuss.elastic.co/t/java-api-searchhitfield-usage/4083/5 "2011-03-12T18:56:15Z")

</div>

Yeah I know and it's not a problem for me, just an violation of OO-  
principles 🙂

Btw: I'm really suprised about the performance of ES - especially the  
caching done to the filtered content really shines.

On 12 Mrz., 18:38, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:

> You can treat the value method as a helper to get the first object in the list if the list is not empty. Otherwise, you can just use the values method that returns a List of objects if thats how you like it.
> 
> On Saturday, March 12, 2011 at 7:09 PM, K.B. wrote:
> 
> > Hey Shay,
> 
> > I understand but as a Java programmer, I still feel uncomfortable:  
> > getting back a List is ok as well as an Object, but those together is  
> > not good; Reason is simply any List is also an object, so to be it  
> > correctly it's just:
> 
> > String name;  
> > Object value;
> 
> > and in case you get back many objects the value is an Object of  
> > interface type List, meaning a single List object 🙂
> 
> > Also in runtime its not sure if you will get back a single object or a  
> > list (remember, we have no schema usually), so you need to care anyway  
> > with the danger of getting an Object holding other object's in it;
> 
> > Following that, the logical consequence for regular SearchHit's is to  
> > strip the class as same behaviour can be achived by giving back a  
> > Map\<String, Object\>;
> 
> > Best
> 
> > On 12 Mrz., 08:13, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> > 
> > > A field, when stored / executed as a script, can be retrieved, and when fetched, it can be of different types (numeric, string, and so on). Thats the reason why the type if Object, if you want the String representation, you can call toString on it.
> 
> > > The reason why it has both value() and values() is because a field can have several values for it indexed (for example, an array of values). So, when stored, you can get the list of values associated with it (in which case, the value method will just return the first one). The reason its a List is because it maintains the order of the values indexed.On Friday, March 11, 2011 at 5:09 PM, K.B. wrote:
> 
> > > Hello,
> 
> > > > when I get back a SearchHit hit, I can get back the fields with  
> > > > hit.getFields();
> 
> > > > This leads to a Map\<String, SearchHitField\> where String is the name  
> > > > of the field and SearchHitField actually is an Interface just having:
> 
> > > > String name();  
> > > > Object value();  
> > > > List values();
> 
> > > > (plus getters with get..);
> 
> > > > Actually is there a special reason there is no Map\<String, String\>  
> > > > hit.getSimpleFields(); or sth. like that in it as I don\*t see the  
> > > > reason to get back a map of Objects that contains the key as String  
> > > > name plus and Object Value that is the content of the field (the idea  
> > > > with List seems bit strange to me - either I get back an  
> > > > Object thst is instance of List or not - but a List is actually an  
> > > > Object when it exists as List itself is just a specialized interface  
> > > > derived from Collection - so, this is not good in terms of OO imho);
> 
> > > > Best

---

<div class="post-metadata">

**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\
**Post date:** [March 12, 2011, 6:57pm UTC](https://discuss.elastic.co/t/java-api-searchhitfield-usage/4083/6 "2011-03-12T18:57:19Z")

</div>

So, I keep missing the violation of OO principles :). What would you suggest be the SearchHitField API? I did not fully understand.  
On Saturday, March 12, 2011 at 8:56 PM, K.B. wrote:

> Yeah I know and it's not a problem for me, just an violation of OO-  
> principles 🙂
> 
> Btw: I'm really suprised about the performance of ES - especially the  
> caching done to the filtered content really shines.
> 
> On 12 Mrz., 18:38, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> 
> > You can treat the value method as a helper to get the first object in the list if the list is not empty. Otherwise, you can just use the values method that returns a List of objects if thats how you like it.
> > 
> > On Saturday, March 12, 2011 at 7:09 PM, K.B. wrote:
> > 
> > > Hey Shay,
> > 
> > > I understand but as a Java programmer, I still feel uncomfortable:  
> > > getting back a List is ok as well as an Object, but those together is  
> > > not good; Reason is simply any List is also an object, so to be it  
> > > correctly it's just:
> > 
> > > String name;  
> > > Object value;
> > 
> > > and in case you get back many objects the value is an Object of  
> > > interface type List, meaning a single List object 🙂
> > 
> > > Also in runtime its not sure if you will get back a single object or a  
> > > list (remember, we have no schema usually), so you need to care anyway  
> > > with the danger of getting an Object holding other object's in it;
> > 
> > > Following that, the logical consequence for regular SearchHit's is to  
> > > strip the class as same behaviour can be achived by giving back a  
> > > Map\<String, Object\>;
> > 
> > > Best
> > 
> > > On 12 Mrz., 08:13, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> > > 
> > > > A field, when stored / executed as a script, can be retrieved, and when fetched, it can be of different types (numeric, string, and so on). Thats the reason why the type if Object, if you want the String representation, you can call toString on it.
> > 
> > > > The reason why it has both value() and values() is because a field can have several values for it indexed (for example, an array of values). So, when stored, you can get the list of values associated with it (in which case, the value method will just return the first one). The reason its a List is because it maintains the order of the values indexed.On Friday, March 11, 2011 at 5:09 PM, K.B. wrote:
> > 
> > > > Hello,
> > 
> > > > > when I get back a SearchHit hit, I can get back the fields with  
> > > > > hit.getFields();
> > 
> > > > > This leads to a Map\<String, SearchHitField\> where String is the name  
> > > > > of the field and SearchHitField actually is an Interface just having:
> > 
> > > > > String name();  
> > > > > Object value();  
> > > > > List values();
> > 
> > > > > (plus getters with get..);
> > 
> > > > > Actually is there a special reason there is no Map\<String, String\>  
> > > > > hit.getSimpleFields(); or sth. like that in it as I don\*t see the  
> > > > > reason to get back a map of Objects that contains the key as String  
> > > > > name plus and Object Value that is the content of the field (the idea  
> > > > > with List seems bit strange to me - either I get back an  
> > > > > Object thst is instance of List or not - but a List is actually an  
> > > > > Object when it exists as List itself is just a specialized interface  
> > > > > derived from Collection - so, this is not good in terms of OO imho);
> > 
> > > > > Best

---

<div class="post-metadata">

**Author:** ![K\_B](https://avatars.discourse-cdn.com/v4/letter/k/278dde/32.png) [@K\_B](https://discuss.elastic.co/u/K_B)\
**Post date:** [March 12, 2011, 7:08pm UTC](https://discuss.elastic.co/t/java-api-searchhitfield-usage/4083/7 "2011-03-12T19:08:35Z")

</div>

I would go the way SOLR went: just drop it - and so just return the  
pure content object - be it a Long, a String or a List etc. -\>  
so field("name") would give back an object that the field-content is,  
instead of Map\<String, SearchHitField\> getFields() it would be  
Map\<String, Object\> getFields();

But as its used by many people it has to be deprecated first.... - or  
let it just like it is and keep this in mind by future refining 😉

BTW: why are nearly all getters existing duplicated? nearly all simple-  
returning-functions exist as e.g.: getObject() and object();?  
(also see SearchHitField interface for an example);

On 12 Mrz., 19:57, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:

> So, I keep missing the violation of OO principles :). What would you suggest be the SearchHitField API? I did not fully understand.
> 
> On Saturday, March 12, 2011 at 8:56 PM, K.B. wrote:
> 
> > Yeah I know and it's not a problem for me, just an violation of OO-  
> > principles 🙂
> 
> > Btw: I'm really suprised about the performance of ES - especially the  
> > caching done to the filtered content really shines.
> 
> > On 12 Mrz., 18:38, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> > 
> > > You can treat the value method as a helper to get the first object in the list if the list is not empty. Otherwise, you can just use the values method that returns a List of objects if thats how you like it.
> 
> > > On Saturday, March 12, 2011 at 7:09 PM, K.B. wrote:
> > > 
> > > > Hey Shay,
> 
> > > > I understand but as a Java programmer, I still feel uncomfortable:  
> > > > getting back a List is ok as well as an Object, but those together is  
> > > > not good; Reason is simply any List is also an object, so to be it  
> > > > correctly it's just:
> 
> > > > String name;  
> > > > Object value;
> 
> > > > and in case you get back many objects the value is an Object of  
> > > > interface type List, meaning a single List object 🙂
> 
> > > > Also in runtime its not sure if you will get back a single object or a  
> > > > list (remember, we have no schema usually), so you need to care anyway  
> > > > with the danger of getting an Object holding other object's in it;
> 
> > > > Following that, the logical consequence for regular SearchHit's is to  
> > > > strip the class as same behaviour can be achived by giving back a  
> > > > Map\<String, Object\>;
> 
> > > > Best
> 
> > > > On 12 Mrz., 08:13, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> > > > 
> > > > > A field, when stored / executed as a script, can be retrieved, and when fetched, it can be of different types (numeric, string, and so on). Thats the reason why the type if Object, if you want the String representation, you can call toString on it.
> 
> > > > > The reason why it has both value() and values() is because a field can have several values for it indexed (for example, an array of values). So, when stored, you can get the list of values associated with it (in which case, the value method will just return the first one). The reason its a List is because it maintains the order of the values indexed.On Friday, March 11, 2011 at 5:09 PM, K.B. wrote:
> 
> > > > > Hello,
> 
> > > > > > when I get back a SearchHit hit, I can get back the fields with  
> > > > > > hit.getFields();
> 
> > > > > > This leads to a Map\<String, SearchHitField\> where String is the name  
> > > > > > of the field and SearchHitField actually is an Interface just having:
> 
> > > > > > String name();  
> > > > > > Object value();  
> > > > > > List values();
> 
> > > > > > (plus getters with get..);
> 
> > > > > > Actually is there a special reason there is no Map\<String, String\>  
> > > > > > hit.getSimpleFields(); or sth. like that in it as I don\*t see the  
> > > > > > reason to get back a map of Objects that contains the key as String  
> > > > > > name plus and Object Value that is the content of the field (the idea  
> > > > > > with List seems bit strange to me - either I get back an  
> > > > > > Object thst is instance of List or not - but a List is actually an  
> > > > > > Object when it exists as List itself is just a specialized interface  
> > > > > > derived from Collection - so, this is not good in terms of OO imho);
> 
> > > > > > Best

---

<div class="post-metadata">

**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\
**Post date:** [March 12, 2011, 7:49pm UTC](https://discuss.elastic.co/t/java-api-searchhitfield-usage/4083/8 "2011-03-12T19:49:51Z")

</div>

Ok, now I understand, and don't agree. There are two separate notions here, a field can have multiple values, and it can be of different types. Those are two different things.  
On Saturday, March 12, 2011 at 9:08 PM, K.B. wrote:

> I would go the way SOLR went: just drop it - and so just return the  
> pure content object - be it a Long, a String or a List etc. -\>  
> so field("name") would give back an object that the field-content is,  
> instead of Map\<String, SearchHitField\> getFields() it would be  
> Map\<String, Object\> getFields();
> 
> But as its used by many people it has to be deprecated first.... - or  
> let it just like it is and keep this in mind by future refining 😉
> 
> BTW: why are nearly all getters existing duplicated? nearly all simple-  
> returning-functions exist as e.g.: getObject() and object();?  
> (also see SearchHitField interface for an example);
> 
> On 12 Mrz., 19:57, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> 
> > So, I keep missing the violation of OO principles :). What would you suggest be the SearchHitField API? I did not fully understand.
> > 
> > On Saturday, March 12, 2011 at 8:56 PM, K.B. wrote:
> > 
> > > Yeah I know and it's not a problem for me, just an violation of OO-  
> > > principles 🙂
> > 
> > > Btw: I'm really suprised about the performance of ES - especially the  
> > > caching done to the filtered content really shines.
> > 
> > > On 12 Mrz., 18:38, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> > > 
> > > > You can treat the value method as a helper to get the first object in the list if the list is not empty. Otherwise, you can just use the values method that returns a List of objects if thats how you like it.
> > 
> > > > On Saturday, March 12, 2011 at 7:09 PM, K.B. wrote:
> > > > 
> > > > > Hey Shay,
> > 
> > > > > I understand but as a Java programmer, I still feel uncomfortable:  
> > > > > getting back a List is ok as well as an Object, but those together is  
> > > > > not good; Reason is simply any List is also an object, so to be it  
> > > > > correctly it's just:
> > 
> > > > > String name;  
> > > > > Object value;
> > 
> > > > > and in case you get back many objects the value is an Object of  
> > > > > interface type List, meaning a single List object 🙂
> > 
> > > > > Also in runtime its not sure if you will get back a single object or a  
> > > > > list (remember, we have no schema usually), so you need to care anyway  
> > > > > with the danger of getting an Object holding other object's in it;
> > 
> > > > > Following that, the logical consequence for regular SearchHit's is to  
> > > > > strip the class as same behaviour can be achived by giving back a  
> > > > > Map\<String, Object\>;
> > 
> > > > > Best
> > 
> > > > > On 12 Mrz., 08:13, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> > > > > 
> > > > > > A field, when stored / executed as a script, can be retrieved, and when fetched, it can be of different types (numeric, string, and so on). Thats the reason why the type if Object, if you want the String representation, you can call toString on it.
> > 
> > > > > > The reason why it has both value() and values() is because a field can have several values for it indexed (for example, an array of values). So, when stored, you can get the list of values associated with it (in which case, the value method will just return the first one). The reason its a List is because it maintains the order of the values indexed.On Friday, March 11, 2011 at 5:09 PM, K.B. wrote:
> > 
> > > > > > Hello,
> > 
> > > > > > > when I get back a SearchHit hit, I can get back the fields with  
> > > > > > > hit.getFields();
> > 
> > > > > > > This leads to a Map\<String, SearchHitField\> where String is the name  
> > > > > > > of the field and SearchHitField actually is an Interface just having:
> > 
> > > > > > > String name();  
> > > > > > > Object value();  
> > > > > > > List values();
> > 
> > > > > > > (plus getters with get..);
> > 
> > > > > > > Actually is there a special reason there is no Map\<String, String\>  
> > > > > > > hit.getSimpleFields(); or sth. like that in it as I don\*t see the  
> > > > > > > reason to get back a map of Objects that contains the key as String  
> > > > > > > name plus and Object Value that is the content of the field (the idea  
> > > > > > > with List seems bit strange to me - either I get back an  
> > > > > > > Object thst is instance of List or not - but a List is actually an  
> > > > > > > Object when it exists as List itself is just a specialized interface  
> > > > > > > derived from Collection - so, this is not good in terms of OO imho);
> > 
> > > > > > > Best

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 4:10am UTC](https://discuss.elastic.co/t/java-api-searchhitfield-usage/4083/9 "2017-07-06T04:10:11Z")

</div>


