A query is implemented by creating an instance of its implementation interface and registering it to default lookup. Queriers should normally not need to see these interfaces directly since there is a matching utility class which aggregates and prioritizes the results automatically. The utility class in the API can also insulate clients from changes in the SPI.

It is expected that only a small number of implementations of a given query interface are actually registered at once, so the critical path for answering it should be relatively short. Where a large number of modules are able to supply information for a query following a common structure, and it is possible to quickly determine which one would know the answer, a multiplexing implementation of the query interface may be registered which can reroute requests directly to a proper implementation of some secondary interface (again registered in default lookup). This technique permits the SPI to be very flexible while keeping a typical API method call fast. For an example, note that only one instance of ProjectFactory is necessary to support all Ant-based projects: each project type is defined using an AntBasedProjectType, and the singleton multiplexer delegates appropriately based on the project type ID found in nbproject/project.xml in the project directory. Therefore adding a new Ant-based project type should not increase the time required to recognize a particular Ant-based project on disk.