Hi, I wanted to subclass StandardTokenizer to manipulate a little with PositionAttribute. I wanted to increase steps between adjacent fields of the same, so if there is a multi-value TextField:
fieldX: "name1 name2", fieldX:"name3 name4" then PhraseQuery like this fieldX:"name2 name3" would not return a result. I was forced to create "empty" values like this: fieldX: "name1 name2", fieldX: "EMPTY_VALUE", fieldX:"name3 name4" to achieve it. Regards, MW On Thu, Jan 12, 2017 at 1:10 AM, Michael McCandless < luc...@mikemccandless.com> wrote: > I don't think it's about efficiency but rather about not exposing > possibly trappy APIs / usage ... > > Do you have a particular class/method that you'd want to remove final from? > > Mike McCandless > > http://blog.mikemccandless.com > > > On Wed, Jan 11, 2017 at 4:15 PM, Michael Wilkowski <m...@silenteight.com> > wrote: > > Hi, > > I sometimes wonder what is the purpose of so heavy "final" methods and > > classes usage in Lucene. It makes it my life much harder to override > > standard classes with some custom implementation. > > > > What comes first to my mind is runtime efficiency (compiler "knows" that > > this class/method will not be overridden and may create more efficient > code > > without jump lookup tables and with method inlining). Is my assumption > > correct or there are other benefits that were behind this decision? > > > > Regards, > > Michael W. >
