It's most obvious for extractors:
It's awfully verbose.
We could remove the intermediary @ annotation:
... but then we wouldn't be able to (later) add a way for users to refer to a container value extractor by its name.
Maybe we could expect the references to container value extractors to be strings only?
Something like this:
That would, however, require us to provide some way for users to register their custom container value extractors.
Ideally we should use a dedicated reference type, but we can't use enums because we expect users to write their own extractors, and we can't use a dedicated interface because that's not allowed in annotations.
Maybe we could shorten the name of the "container value extractor reference" annotation (we'd have to do the same for other "reference" annotations), and allow to use either enums for built-in types, or class/string for custom types.
Something like this:
And for value bridges:
If we go down that route, here is the to-do list:
Rename the *BeanReference annotations: remove the BeanReference suffix
Merge the *Bridge and *BridgeBuilder annotations: wherever we have a bridge and bridgeBuilder attributes in an annotation, just keep bridge, but make sure that the type of that annotation has four attributes: name, type, builderName, builderType. Keep the same constraints as today, i.e. you can refer to a bridge directly (through name and/or type) or to a builder (through builderName/builderType), but never both in the same annotation.
Rename the ContainerValueExtractorBeanReference annotation to ContainerExtractor
Rename the ContainerValueExtractor class to ContainerExtractor (and also rename related classes such as ContainerValueExtractorPath)
Introduce a BuiltinContainerExtractor enum, with one value per available built-in container extractor + AUTOMATIC.
Change ContainerExtractorPath so that it uses enums as well as classes to refer to extractors. We will probably have to change it to a linked list. The “default” container extractor path will simply be a container extractor path with one element whose value is BuiltinContainerExtractor.AUTOMATIC
Change ContainerExtractorBinder so that it recognizes these enums.
Add a “value” attribute to the ContainerExtractor annotation, of type BuiltinContainerExtractor, and make sure to propagate when creating the corresponding ContainerExtractorPath.
Replace uses of ContainerExtractor.type in tests with ContainerExtractor.value wherever we refer to built-in container extractor types
Move built-in container extractor types to an impl package.
Once it’s done, let’s talk again about what could be done for value bridges, especially built-in value bridges. Maybe just create another ticket.