"ServiceClasspathSubItem is intended for client side filtering of lookup * service results prior to clients using a service, the lookup service * that implements this class, implements #getServiceItem(), so clients * can obtain a complete ServiceItem when required after filtering."
I'm still wondering if it wouldn't be better for a client to send a list of Entry's it's interested in seeing, separate from the set for matching to the Registrar. The Registrar can then return ServiceItems for the matches and pre-filter the Entry's per item. Especially given: "Some fields in ServiceClasspathSubItem may be null, fields in Entry's may * be null or even the service reference may be null, these fields would be * non-null in a ServiceItem that resolves classes from dynamicly downloaded * code or a remote codebase." I think, if we do the filtering as I suggest, much of the comment re: nulls above still applies in implementation but ultimately, the client will pick Entry's for which it has the classpath such that it always deals in complete Entry's and can have a level of predictability in respect of what is or is not null. This might save clients having to do endless null checks etc that can be a rich source of bugs and ugly code. We might need the filter list to include specific subclasses as well....
