I agree - enforce delegation, finalize what shouldn't be ever overridden by subclasses of such a filter. It makes things much easier for debugging.
If you have the time to proceed, it would be very interesting if all the tests pass with such a change. I suspect there will be surprises. Dawid On Wed, Dec 10, 2025 at 12:43 PM Benjamin Lerer <[email protected]> wrote: > Hi everybody, > > I recently opened #15452 <https://github.com/apache/lucene/issues/15452> > because > FilterIndexInput and FilterIndexOutput do not always delegate calls to > the instances that they decorate which can cause them to override the > behavior of the instances they are delegating to. > > For example, it is possible in your own IndexInput implementation to > override readMapOfStrings but if an instance of this class is decorated > by a FilterIndexInput then when readMapOfStrings is called the logic that > will be called is the one of DataInput.readMapOfStrings. > > This behavior is not the expected one and is time consuming to debug. > After some discussion on the Github issue, I started to work on an initial > patch to address that problem. > > It turns out that the behavior is not consistent within the code. Some > Decorators (Filter) delegate everything and other ones assume without > enforcing it (marking methods as final) that only abstract methods should > be overridden (even sometimes relying on it). > > Before moving forward with the patch, I wanted to raise the visibility of > that problem to ensure that everybody is aligned and that I do not miss > some important information. > > My proposal would be to enforce delegation in the Filter classes and use > final for the methods that we know should never be overridden but I would > love to hear your feedback first. > >
