Compatibility with Solr 9.7 and Lucene 9.11 (fixes #457) #461
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jbaiter
force-pushed
the
solr-9.7
branch
2 times, most recently
from
7bd2d32 to
ab3a2a0
Compare
This one was fun. Lucene 9.11 changed the signature for the `FieldHighlighter` constructor to add an 8th parameter. This meant that we had to call different constructors for different Solr/Lucene versions. Unfortunately, Java requires that the superclass constructor invocation must be the first top-level statement in a subclass constructor, i.e. dynamic selection is not possible in Java. It is however no problem at the bytecode level, and so we supply a handcrafted (via `jasm`) `FieldHighlighterAdapter.class` that does the dynamic superclass constructor invocation. It's shipped as a precompiled .class (along with the commented .jasm source code and build instructions) since I could not for the life of me figure out how to integrate jasm into the maven build. Maven woes also required removing the JavaDoc plugin, since that was unable to pick up the .class from the resources directory. Since the plugin is not really used as a library anyway, I think this is an acceptable tradeoff.
Revert the whole bytecode approach, just remove the tight coupling introduced by the inheritance and it's compatible with all Lucene versions without nasty hacks.
schmika
approved these changes
Sep 13, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This one was fun. Lucene 9.11 changed the signature for theFieldHighlighterconstructor to add an 8th parameter.This meant that we had to call different constructors for different Solr/Lucene versions. Unfortunately, Java requires that the superclass constructor invocation must be the first top-level statement in a subclass constructor, i.e. dynamic selection is not possible in Java. At least until Java 23 when JEP 482 landed.It is however no problem at the bytecode level, and so we supply a handcrafted (viajasm)FieldHighlighterAdapter.classthat does the dynamic superclass constructor invocation.It's shipped as a precompiled .class (along with the commented .jasm source code and build instructions) since I could not for the life of me figure out how to integrate jasm into the maven build.Maven woes also required removing the JavaDoc plugin, since that was unable to pick up the .class from the resources directory. Since the plugin is not really used as a library anyway, I think this is an acceptable tradeoff.Turns out there was actually no need for the tight coupling through inheritance. Getting rid of the subclassing frorm
FieldHighlighterwas very simple and now it works with all supported Lucene versions without weird hacks.