Hi, Analysis components are not intended to be subclassed, because they follow another programming pattern. All components in Lucene around TokenStreams/Tokenizers and Analyzers are using the "decorator pattern" (similar to InputStreams in Java IO). You combine them by wrapping, similar like adding FilterInputStreams like BufferedInputStream on to of the original analyzer. Wuld you ever subclass FileInputStream? - No - you won't. You would wrap it with a filter. Lucene is following the same pattern.
To customize an analyzer, do the following: subclass AnalyzerWrapper and override wrapComponents(), see https://lucene.apache.org/core/6_3_0/core/org/apache/lucene/analysis/AnalyzerWrapper.html. Done. :-) But instead of manually creating the Analyzer by subclassing, it is much easier to use CustomAnalyzer, which provides a builder to "configure" analysis. No subclassing needed! See https://lucene.apache.org/core/6_3_0/analyzers-common/org/apache/lucene/analysis/custom/CustomAnalyzer.html Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -----Original Message----- > From: Kumaran Ramasubramanian [mailto:kums....@gmail.com] > Sent: Thursday, January 12, 2017 2:53 AM > To: java-user@lucene.apache.org > Subject: Re: Heavy usage of final in Lucene classes > > Hi > > I want to know the purpose of having final in analyzers. > > For eg: classicanalyzer. It will be easy to add asciifolding filter over > classicanalyzer. > > > - > Kumaran R > > On Jan 12, 2017 5:41 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. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
