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 '.'? Mike On Tue, Feb 23, 2010 at 1:42 AM, Shai Erera <ser...@gmail.com> 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: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
