[
https://issues.apache.org/jira/browse/LUCENE-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14000695#comment-14000695
]
Uwe Schindler commented on LUCENE-5663:
---------------------------------------
I think the main problem here is just the name "open()". The problem here is
that "NIOFSDir.open()" reads like "open a NIOFSDir". I agree with Hoss, that
this is the standard,well known factory pattern and this problem with it
applies to other cases, too (you can also call
{{Lucene43Codec.forName("Lucene3x")}} which is also bullshit. But here it is
obvious from the method name that forName relates to a factory.
So people should really listen to their Eclipse warning (better would be to
have it as error and Java should not allow access to static methods on
subclasses).
The better fix is in my opinion to just rename the method to a better name:
{{FSDirectory.newPlatformDefault(...);}} Then no need to shadow them and its
more obvious, that this is a "factory" method.
In 4.x we can still provide a deprecated open(), which is shadowed in the
subclasses and throws UOE in subclasses.
> Fix FSDirectory.open API
> ------------------------
>
> Key: LUCENE-5663
> URL: https://issues.apache.org/jira/browse/LUCENE-5663
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
>
> Spinoff from LUCENE-5658
> {quote}
> This does not use NIOFSDir! open() is a static factory method on FSDirectory,
> just inherited to NIOFSDirectory.
> {quote}
> I think its confusing we have this method on FSDirectory, so its visible in
> subclasses. We should at least consider doing this in another way so its not
> confusing.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
