Uploaded image for project: 'Lucene - Core'
  1. Lucene - Core
  2. LUCENE-4675

remove *Ref.copy/append/grow

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • None
    • None
    • None
    • None
    • New

    Description

      These methods are dangerous:

      In general if we want a StringBuilder type class, then it should own the array, and it can freely do allocation stuff etc. this is the only way to make it safe.

      Otherwise if we want a ByteBuffer type class, then its reference should be immutable (the byte[]/offset/length should be final), and it should not have allocation stuff.

      BytesRef is none of these, its like a C pointer. Unfortunately lucene puts these unsafe, dangerous, trappy APIs directly in front of the user.

      What happens if i have a bug in my application and it accidentally mucks with the term bytes returned by TermsEnum or the payloads from DocsAndPositionsEnum? Will this get merged into a corrupt index?

      I think as a start we should remove these copy/append/grow to minimize this closer to a ref class (e.g. more like java.lang.ref and less like stringbuilder). Nobody needs this stuff on bytesref, they can already operate on the bytes directly.

      Attachments

        Activity

          People

            Unassigned Unassigned
            rcmuir Robert Muir
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: