This looks like a leftover indeed an I think it can be removed, but maybe @javanna can take a second look?

what is unused is unused :) I have no idea how it became unused though.

I think NamedWriteableAwareStreamInput was introduced just a bit later. Only my guess.

A value if 0 seems to be okay here. At least there are some tests in SuggestSearchTests (unfortunately in the lang-mustache module) that use that and now fail with an exception.

@s1monw Wanted to get your input on the method below. Its meant to be a convenience method for taking an input string (e.g. a JSON parameter) and converting it to an enum, in the situation where the enum element does not have the same name as the input string (and hence, can't use Enum.valueOf). A common case is where we name the enum element in all upper case but the string value is in lower case.

I like the trick here but I think it's too much magic after all. Can we stick to switch / case and ordinals - it's something everybody understands without reading up on it? WDYT

Plus I just realized that sometimes we have more than one variant of an enum value in the query DSL (e.g. camel casing etc.) that needs to be mapped to one enum. For example, the StringDistance currently allows both "damerau_levenshtein" and "damerauLevenshtein". This might be something to get rid of, but in the meantime we need to support it I think.

@s1monw @cbuescher Good points, especially with the multiple variants for any given enum value that Christoph mentioned, this interface provides no added benefit then. I'll take it out.

This probably shouldn't be nullable. We have the zero-arg constructor above for when a no name is needed so maybe we should throw an exception if the name is null here so the user is alerted to the fact that the variable they are passing in is null?

Good point, but my personal opinion here is that if the value is optional we should allow null. It would be different if this can overwrite a default settings, but thats not the case here. I'm not a big fan of the annotation though.

I figured the annotation would declare the intent clearly. I think the bigger issue is deciding if name can be null or not and then build a consistent API for the builder that allows to set the value consistently (i.e. everywhere the property can either be null or everywhere it is prohibited from being null). Just my two cents.