my main motivation for this is a little project i'm working on in some spare time to try and build a reflection based tool that will help us autogenerate Factories whenever we upgrade the Lucene jar. step one is identifying which TokenFilter and Tokenizer factories already exist (even though the names might be inconsistent). for that specific use case i could also introduce some new annotations, but it got me thinking about this and i think it's a good idea in general. It makes the API of each factory self documenting about what that factory produces, and makes hte javadocs a lot easier to follow.
no functionality is changed, and it is 100% backwards compatible.
i'm seeking comments before commiting however because it does violate the typical philosophy of an API: declare that you return an interface/abstract class, not a concrete implementation. I'm not sure that is as important in the case of these factories. it also (in theory) could cause problems down the road if we start optimizing the factories. ie: if we decide that for certain input options, SynonymFilterFactory isn't going to return a SynonymFilter and instead will return some new AliasFilter then in theory we have painted ourselves into a corner unless this AliasFilter is a subclass of SynonymFilter because people might have written code that directly calls the create method on the factory and expects a specific return type. likewise we might run into similar problems if we promote some of our own filters up into lucene (and the packages change)
these seem like minor concerns however, given the intended usecase of these factories, and the "self documentation" benefits of the API.
...but that's just my opinion, which is why i wanted to put it out there and see what people think.