Technically, the field is a JGroups Address, which is an interface. I've never seen any implementation other than the JGroups UUID actually be used though. A JGroups UUID is not a subclass of java.lang.UUID.

Ok. So, since this type is not known to Search you will need to provide your own bridge implementation.

Why are the bridge implementation classes not part of the public API?

So that we can change the implementation as we want. For built-in bridges the discovery mechanism should determine the right bridge. For types unknown to Search, you need to specify your own bridge implementation. Note, that in Search 5 you will also be able to register bridges for "unkown" types via a so called BridgeProvider (see

I'm assuming that means I shouldn't be using anything in the org.hibernate.search.bridge.builtin.impl package,

That's correct. The use of any calls having an impl in its package name is discouraged. We don't guarantee how these classes evolve or might even remove them without prior warning. Maybe it is arguable whether DefaultStringBridge should be made a public bridge, but right not it is not.

I'm also using BuiltinIterableBridge,

In which context? How?

so I guess I'd need to subclass IterableBridge instead in order to get a bridge that can handle an Iterable and also has a no-arg constructor. But BuiltinIterableBridge already does that, so again, it seems silly to need to define another class to do the exact same thing.

Correct. On the other hand, by defining your own class you have full control over your bridges.

I guess we can discuss whether some bridges should be made public, but then they need to move packages as well. Just adding a public constructor is undermining the whole intention of impl packages.