Adrien Grand

I have some interest in this change too so I ported it to the current codec in a way that looks a bit less invasive as suggested above: https://github.com/apache/lucene/pull/827

@iverase Can you expand on why this would be an issue for backward compatibility?

I like the CorruptIndexException because it tells me that the problem is that the file got altered after being written, while I would otherwise wonder if there is a bug...

I repurposed this PR to instead make the test expect out-of-bounds exceptions. Does it look better to you @rmuir @uschindler ?

@neophob The benchmarks have been run on my desktop, I would not be surprised that one would get very different results on an ARM system. Can you check which xxhash...

@odaira Would you accept a PR that implements the above proposal?

That's an interesting question. When I wrote the API, I hesitated between going with an int or a long whose 32 lower bits would be used, but preferred the int...

This sounds like a good start to me!

I guess a trade-off would be to expose a compression "state" so that consumers could decide to allocate on demand (as today) or to cache depending on their needs?

Agreed we should look into this! I opened https://issues.apache.org/jira/browse/LUCENE-9959.