https://github.com/hibernate/hibernate-search/pull/710

Right it makes sense to expose a public one way bridge that simply calls toString. ToStringBridge or something like that.

I can understand wanting to keep certain classes out of the public API, but it would be nice if Hibernate Search provided bridges for user-defined classes in common situations, like DefaultStringBridge.

I hear you. DefaultStringBridge might be a special case indeed. An alternative could be to have a special option in the DSL which basically implies that if the indexed type is not known to Search the default toString bridge should be used. This would keep the DefaultStringBridge still private, but allows to handle the cases where a simple toString would be sufficient.

The BuiltinIterableBridge is being used on a field that is a Set<String>.

I can understand wanting to keep certain classes out of the public API, but it would be nice if Hibernate Search provided bridges for user-defined classes in common situations, like DefaultStringBridge.

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 HSEARCH-1552).

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.