You mean if IndexReader.getCommitUserData() is faster than IndexReader.open().getIndexCommit().getUserData()? Do I really need to benchmark this !?
Nope, but thats not really the question. I mean in the full picture of the application, is there another way?
The static method just reads the SegmentInfos and returns the commitData. Opening an IndexReader at least opens its all sub-segments, loads norms, deleted docs and what not.
wait, i dont think thats totally true. Opening the static method may or may not also read in fieldinfos (as they are tied to segmentinfos in trunk currently). Opening an indexreader doesnt load norms until you ask for them, for example.
Look, it's not like I'm trying to add a new API. It existed for a long time, and it happens to be that I'm using it (and maybe others who didn't speak up). So why deprecate it?
Well I thought the API was confusing, especially the overloaded names, but when looking into it, I started to question why it needs to exist.
I think this is ok: we can't keep adding and adding, I think its good to try to hide some of this stuff.
Especially in Lucene's trunk: lots of things in o.a.l.index (SegmentInfos, public ctors to SegmentReader, etc) don't really need to be public anymore IMO,
some of this was expert workarounds for the fact we didn't have an extensible codecs package. We shouldn't try to support 2 "apis" from this perspective,
accessing parts of the index through expert methods and at the same time having a codec api.
I'm also using it in the SearcherTaxoManager (not yet uploaded to
LUCENE-3786) to inspect the commit data on the taxonomy directory before I create a new DirTaxoReader, which is very expensive. So why nuke it?
Well its still available in 3.x as deprecated methods... were you planning on making a patch against 3.x for
here's an idea: how about we defer this discussion until we see your patch? If it makes sense for
LUCENE-3786, then we have a valid use case?