[ https://issues.apache.org/jira/browse/LUCENE-8248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437864#comment-16437864 ]
ASF subversion and git services commented on LUCENE-8248: --------------------------------------------------------- Commit ffa1bf7a0a206dd2fbdf4a1ad68b8f00f250a20f in lucene-solr's branch refs/heads/branch_7x from Mike McCandless [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ffa1bf7 ] LUCENE-8248: remove duplicate method; fix test to reference FilterMergePolicy > Rename MergePolicyWrapper to FilterMergePolicy and override all of MergePolicy > ------------------------------------------------------------------------------ > > Key: LUCENE-8248 > URL: https://issues.apache.org/jira/browse/LUCENE-8248 > Project: Lucene - Core > Issue Type: Wish > Components: core/index > Reporter: Mike Sokolov > Priority: Minor > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8248.1.patch, LUCENE-8248.2.patch, > LUCENE-8248.patch, LUCENE-8248.patch, MergePolicy.patch > > > MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is > not, which means that overriding it with anything other than a trivial > delegation can only lead to confusion. > The patch makes the method final and removes the trivial implementations from > MergePolicyWrapper and NoMergePolicy. > [~mikemccand] also pointed out that the class name is nonstandard for similar > adapter classes in Lucene, which are usually Filter*.java. Personally I was > looking for MergePolicyAdapter, but if there is a prevailing convention here > around Filter, does it make sense to change this class's name to > FilterMergePolicy? -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org