One thing that would have to change, in particular, is that we'd organize metadata differently. For instance, we currently have a hierarchy:

TypeMetadata
   => DocumentFieldMetadata
      => Facet metadata
      => BridgeDefinedField
   => PropertyMetadata
      => List of sortable fields

There are multiple issues with this hierarchy:

• Java properties are mixed with document fields. Ideally, we'd want to keep a clear separation between those, or at the very least making access to Java metadata totally optional from indexing service specific bridges (everything that's necessary should be in the "generic document" metadata)
• Bridge-defined fields are second-class citizens, whereas they should be as

One possibility would be something like that:

TypeMetadata
   => GenericBridgeMetadata
      => 1 java accessor (whole type or property)
      => 1 bridge
      => Multiple resulting fields metadata (either defined in the mapping or by the bridge)
         => Properties: type, is it sortable, is it stored, ...

To achieve this, we'd probably have to make a clear distinction between simple bridges (one java object instance => one document field value) and more complex ones (one java object instance => multiple document field values). When mapping, some attributes would only make sense for simple bridges, such as the field name, the "sortable" attribute, ... This would probably result in two distinct annotations: maybe @Field (single field, optionally with a simple transformation function) and @Bridge (defines its own implementation-dependent set of fields)?