This model will encourage people to use BaseFieldBridgeOptions as the base implementation. This will be future proof as we can offer a default sensible implementation.

BridgeOptions.java

public interface FieldBridge { //could be an additional interface if that's better
    [...]
    FieldBridgeOptions getOptions();
}

interface FieldBridgeOptions {
    /** 
     * List of properties read by the class bridge
     */
    String[] getPropertiesRead();

    /**
     * List of lucene fields needed to read stored value
     */
    String[] getLuceneFieldsInvolved();

    /**
     * Get field descriptor as exposed by the metadata
     */
    Set<FieldDescriptor> getFieldDescriptors(FieldDescriptor baseDescriptor);
}

class BaseFieldBridgeOptions implements FieldBridgeOptions {
    public static final String[] DEFAULT_PROPERTY = new String { "_DEFAULT_PROPERTY" };
    public static final String[] ALL_PROPERTIES = new String { "_ALL_PROPERTIES" };
    public static final String[] DEFAULT_FIELD = new String { "_DEFAULT_FIELD" };
    public static final String[] ALL_FIELDS = new String { "_ALL_FIELDS" };

    @Override
    public String[] getPropertiesRead() { return DEFAULT_PROPERTY; }

    @Override
    public String[] getLuceneFieldsInvolved() { return DEFAULT_FIELD; }

    @Override Set<FieldDescriptor> getFieldDescriptors(FieldDescriptor baseDescriptor) {
        Set<FieldDescriptor> result = new HashSet<FieldDescriptor>(1);
        result.add(baseDescriptor);
        return result;
    }
}
    

I think any additions, like in your case getOptions should be defined on a separate inerface. Adding it to FieldBridge directly will break existing implementations and I like the idea of independent field bridge "traits".

Speaking of individual traits/interfaces. I would not add getPropertiesRead and the Lucene field related methods into the same interface. getPropertiesRead is really only relevant for class bridges and as such should only be implemented by them.

I think we also agreed that for now we defer the reporting of read properties. @Sanne's concern was that we cannot validate that only the specified properties are read in which case we might skip required index updates in some cases. Personally I would be fine with that though.

Regarding getLuceneFieldsInvolved , I am not sure whether we need it. I guess this tries to cover the projection case, right? Or better the case where a field bridge generates more than one field, but only reports a single field to the metadata API, however, for projection we need to load all relevant fields? Is the spatial bridge an example for that?

Either way, maybe we can add something to FieldDescriptor, e.g. isOpaque. This way the field bridge can return all Lucene fields and there is no need for the getLuceneFieldsInvolved.

Just a minor detail: could the methods return a set or list instead of arrays?

@gunnarmorling are you in the business of selling more memory ;P

@hferentschik I also thought that properties only applied for ClassBridge but it turns out it might apply for FieldBridge on associations or collections.

My real concern with traits as you call them. Or a bunch of random interfaces as I would call them is that there is absolutely no clue for the FB developer that they exist or that a new one has been added. I see this as a huge defect.

I agree with you that even if we can't verify it, we still should offer that. It is the contract we have between the FB writer and the core engine. One does not write a bridge by accident.

@hferentschik interesting thinking around FieldDescriptor.isOpaque but it seems we are back to mixing different concepts.
For example, we want to expose coordinates as the synthetic field which has no physical meaning and project coordinates_HSSI_Latitude and coordinates_HSSI_Longitude. In the range case it sort of make sense to not make them opaque actually and in the quad tree approach, projecting them does not make a lot of sense as we can't reconstruct the coordinates AFAIK.
But a "number" field projecting to different fields might be a good candidate.

What I am getting at I guess is that when someone uses the metadata API he will react differently to a synthetic field or a physocal field that should be hidden. For example the query DSL only works with simple field and synthetic fields. But a plain Lucene query cannot use the synthetic fields. We are again back to the use case problem.