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 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.

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 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.

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.

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.