You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Uwe Schindler (JIRA)" <ji...@apache.org> on 2009/07/18 00:16:15 UTC

[jira] Created: (LUCENE-1753) Make not yet final core/contrib TokenStream/Filter implementations final

Make not yet final core/contrib TokenStream/Filter implementations final
------------------------------------------------------------------------

                 Key: LUCENE-1753
                 URL: https://issues.apache.org/jira/browse/LUCENE-1753
             Project: Lucene - Java
          Issue Type: Task
          Components: Analysis
            Reporter: Uwe Schindler
             Fix For: 3.0


Lucene's analysis package is designed in a way, that you can plug different *implementations* of analysis in chains of TokenStreams and TokenFilters. An analyzer is build of several TokenStreams/Filters that do the tokenization of text. If you want to modify the behaviour of tokenization, you implement a new subclass of TokenStream/-Filter/Tokenizer.

Most classes in the core are correctly implemented like that. They are itsself final or their implementation methods are final (CharTokenizer).

A lot of problems with backwards-compatibility of LUCENE-1693 are some classes in Lucene's core/contrib not yet final:
- KeywordTokenizer should be declared final or its implementation methods should be final
- StandardTokenizer should be declared final or its implementation methods should be final
- ISOLatin1Filter is deprecated, so it will be removed in 3.0, nothing to do.

CharTokenizer is the abstract base class of several other classes. The design is correct: Child classes cannot override the implementation, they can only change the behaviour of this final implementation.

Contrib should be checked, that all implementation classes are at least final or they are designed in the same way like CharTokenizer.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


[jira] Resolved: (LUCENE-1753) Make not yet final core/contrib TokenStream/Filter implementations final

Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/LUCENE-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Uwe Schindler resolved LUCENE-1753.
-----------------------------------

    Resolution: Fixed
      Assignee: Uwe Schindler

Committed revision: 824116

> Make not yet final core/contrib TokenStream/Filter implementations final
> ------------------------------------------------------------------------
>
>                 Key: LUCENE-1753
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1753
>             Project: Lucene - Java
>          Issue Type: Task
>          Components: Analysis
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>             Fix For: 3.0
>
>
> Lucene's analysis package is designed in a way, that you can plug different *implementations* of analysis in chains of TokenStreams and TokenFilters. An analyzer is build of several TokenStreams/Filters that do the tokenization of text. If you want to modify the behaviour of tokenization, you implement a new subclass of TokenStream/-Filter/Tokenizer.
> Most classes in the core are correctly implemented like that. They are itsself final or their implementation methods are final (CharTokenizer).
> A lot of problems with backwards-compatibility of LUCENE-1693 are some classes in Lucene's core/contrib not yet final:
> - KeywordTokenizer should be declared final or its implementation methods should be final
> - StandardTokenizer should be declared final or its implementation methods should be final
> - ISOLatin1Filter is deprecated, so it will be removed in 3.0, nothing to do.
> CharTokenizer is the abstract base class of several other classes. The design is correct: Child classes cannot override the implementation, they can only change the behaviour of this final implementation.
> Contrib should be checked, that all implementation classes are at least final or they are designed in the same way like CharTokenizer.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org