lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Earwin Burrfoot (JIRA)" <>
Subject [jira] Commented: (LUCENE-1748) getPayloadSpans on should be abstract
Date Thu, 16 Jul 2009 14:52:14 GMT


Earwin Burrfoot commented on LUCENE-1748:

I took a glance at the code, the whole getPayloadSpans deal is a herecy.

Each and every implementation looks like:
  public PayloadSpans getPayloadSpans(IndexReader reader) throws IOException {
    return (PayloadSpans) getSpans(reader);

Moving it to the base SpanQuery is broken equally to current solution, but yields much less
strange copypaste.

I also have a faint feeling that if you expose a method like
ClassA method();
you can then upgrade it to
SubclassOfClassA method();
without breaking drop-in compatibility, which renders getPayloadSpans vs getSpans alternative
totally useless

> getPayloadSpans on should be abstract
> ------------------------------------------------------------------------------
>                 Key: LUCENE-1748
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Query/Scoring
>    Affects Versions: 2.4, 2.4.1
>         Environment: all
>            Reporter: Hugh Cayless
>             Fix For: 2.4.2
> I just spent a long time tracking down a bug resulting from upgrading to Lucene 2.4.1
on a project that implements some SpanQuerys of its own and was written against 2.3.  Since
the project's SpanQuerys didn't implement getPayloadSpans, the call to that method went to
SpanQuery.getPayloadSpans which returned null and caused a NullPointerException in the Lucene
code, far away from the actual source of the problem.  
> It would be much better for this kind of thing to show up at compile time, I think.
> Thanks!

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message