lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Wilkowski ...@silenteight.com>
Subject Re: Heavy usage of final in Lucene classes
Date Thu, 12 Jan 2017 11:05:46 GMT
Perfect! Thanks, that is what I was looking for :-).

MW


On Thu, Jan 12, 2017 at 12:02 PM, Alan Woodward <alan@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.
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message