If for some reason you are not using quasi-succinct indices (but you shouldn't be), once you are convinced that your setup is reasonable you should generate a wired BitStreamIndexReader/BitStreamHPIndexReader. The latter are the generic classes used by MG4J to read an index: thus, they incorporates all the logic required to handle literally hundreds of types of indices. However, you can use the Ruby script genbitstreamreaders.rb provided with MG4J to generate additional instances that are wired to a specific index type. When loading an index, MG4J will fetch dynamically (by reflection) the wired class and will log (at INFO level) that it is using a wired class instead of the generic class. (The standard MG4J distribution contains wired classes for the default index-construction options.)

The Ruby script above prints a list of commands involving a C compiler (by default, gcc). Actually, the commands use the C preprocessor to filter a driver file contained in the source tree (BitStream[HP]IndexReader.c). Executing the output of the Ruby script will generate all possible wired classes (hundreds), but you can also select manually the classes you prefer to generate.

The simplest way to understand the wiring process is having a look at the output of the Ruby script: essentially, defining the symbol GENERIC you obtain the generic driver. Otherwise, you can define symbols SKIPS and PAYLOADS if you want these features, and then you must specify assertions with name frequencies, pointers, counts, and positions that either select a code or disable a feature (as in Combine's command line options). The symbol CLASSNAME defines the wired class name, and must be generated following the algorithm contained in the Ruby script, or MG4J will mistakenly load wired classes that are not adapt for your index.