[
https://issues.apache.org/jira/browse/LUCENE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16712767#comment-16712767
]
Uwe Schindler commented on LUCENE-8566:
---------------------------------------
Hi, in fact there is no difference between the two calls. Yes, the clas sname
is an implementation details if you purely see it from the standpoint of
somebody using "configuration" files. But those people get an error message on
startup of the server.
For people building a custom analyzer from source code, using class names or
constants help them when using their IDE's autocompletion. To them it does not
matter if they write ".class" or ".NAME" or just use a "string" as is.
About the implementation - My proposal would be:
- Add a "NAME" static public final String field to all factories (similar like
Elasticsearch is doing this).
- In the SPI code, we use reflection to lookup the static field named "NAME"
for every class we discovered. We use the found name to register the factory
class for lookup in "Factory.forName()".
> Deprecate methods in CustomAnalyzer.Builder which take factory classes
> ----------------------------------------------------------------------
>
> Key: LUCENE-8566
> URL: https://issues.apache.org/jira/browse/LUCENE-8566
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
> Reporter: Tomoko Uchida
> Assignee: Uwe Schindler
> Priority: Minor
>
> CustomAnalyzer.Builder has methods which take implementation classes as
> follows.
> - withTokenizer(Class<? extends TokenizerFactory> factory, String... params)
> - withTokenizer(Class<? extends TokenizerFactory> factory,
> Map<String,String> params)
> - addTokenFilter(Class<? extends TokenFilterFactory> factory, String...
> params)
> - addTokenFilter(Class<? extends TokenFilterFactory> factory,
> Map<String,String> params)
> - addCharFilter(Class<? extends CharFilterFactory> factory, String... params)
> - addCharFilter(Class<? extends CharFilterFactory> factory,
> Map<String,String> params)
> Since the builder also has methods which take service names, it seems like
> that above methods are unnecessary and a little bit misleading. Giving
> symbolic names is preferable to implementation factory classes, but for now,
> users can write code depending on implementation classes.
> What do you think about deprecating those methods (adding {{@Deprecated}}
> annotations) and deleting them in the future releases? Those are called by
> only test cases so deleting them should have no impact on current lucene/solr
> codebase.
> If this proposal gains your consent, I will create a patch. (Let me know if I
> missed some point. I'll close it.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
