You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Michael Wilkowski <mw...@silenteight.com> on 2017/01/11 21:15:47 UTC
Heavy usage of final in Lucene classes
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.
Re: Heavy usage of final in Lucene classes
Posted by Michael Wilkowski <mw...@silenteight.com>.
Perfect! Thanks, that is what I was looking for :-).
MW
On Thu, Jan 12, 2017 at 12:02 PM, Alan Woodward <al...@flax.co.uk> wrote:
> Hi Michael,
>
> You want to set the positionIncrementGap - either wrap your analyzer with
> an AnalyzerWrapper that overrides getPositionIncrementGap(), or use a
> CustomAnalyzer builder and set it there.
>
> Alan Woodward
> www.flax.co.uk
>
>
> > On 12 Jan 2017, at 10:57, Michael Wilkowski <mw...@silenteight.com> wrote:
> >
> > 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 <
> > lucene@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 <mw...@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.
> >>
>
>
Re: Heavy usage of final in Lucene classes
Posted by Alan Woodward <al...@flax.co.uk>.
Hi Michael,
You want to set the positionIncrementGap - either wrap your analyzer with an AnalyzerWrapper that overrides getPositionIncrementGap(), or use a CustomAnalyzer builder and set it there.
Alan Woodward
www.flax.co.uk
> On 12 Jan 2017, at 10:57, Michael Wilkowski <mw...@silenteight.com> wrote:
>
> 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 <
> lucene@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 <mw...@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.
>>
Re: Heavy usage of final in Lucene classes
Posted by Michael Wilkowski <mw...@silenteight.com>.
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 <
lucene@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 <mw...@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.
>
RE: Heavy usage of final in Lucene classes
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
> -----Original Message-----
> From: Kumaran Ramasubramanian [mailto:kums.134@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"
> <lu...@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 <mw...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Heavy usage of final in Lucene classes
Posted by Kumaran Ramasubramanian <ku...@gmail.com>.
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" <lu...@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 <mw...@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Heavy usage of final in Lucene classes
Posted by Michael McCandless <lu...@mikemccandless.com>.
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 <mw...@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org