lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: IndexFileNames
Date Tue, 23 Feb 2010 11:16:53 GMT
This class makes me somewhat nervous, with the changes coming in flex,
because the extensions are no longer static but rather a function of
the particular codec you're using in the index.  I've changed some of
the constants accordingly (on flex).

Still, I think it's OK to make it public (flex has in fact done so,
since codecs, in different packages, need to reference the constants),
but mark it as @lucene.internal.

There is no back compat issue here -- it's package private currently.
Even once it's public with @lucene.internal, there's still no back
compat since it's internal.

I would love to never do our own concatenation in Lucene's sources,
and instead consistently use IndexFileNames.segmentFileName method
whenever we need to build up a file.  Then it's OK that the extensions
do not include the '.'?


On Tue, Feb 23, 2010 at 1:42 AM, Shai Erera <> wrote:
> Hi,
> I've noticed that IFN is package private, including its constants and
> methods. Any reason why not make it public? I need to create my own
> Directory, and would like to query whether a file is 'my file' or Lucene's
> file. Getting access to the extensions can help. Currently I have to put my
> code in o.a.l package, which I prefer not to.
> Also, I think the constants could be wrong in some situations. They only
> include the extension itself, w/o the "." part. That leads to many places in
> the code where I see this <code>fname + "." + IFN.extension</code>. Two
> problems:
> (1) Doing "." + ext is just a waste - it's really not needed.
> (2) If someone only checks for the extension, without adding the "." part,
> he can accidentally think that fnamedel is a deletion file ..
> I'd like to patch this, but want to validate with the community before I
> create an issue. Making it public is trivial. Changing the extension name is
> more problematic for back-compat, but I think currently it's just wrong ...
> Unless we come up w/ new names for the extensions, which is annoying. Can we
> sacrifice back-compat for this thing?
> Thanks,
> Shai

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message