I'm not talking about Android support – that's a much larger (and
more challenging) question.
I'm talking about relying on as few dependencies (including java APIs)
as possible, to reduce the chance of problems. This philosophy
applies all across lucene sources, but especially to our very low
level APIs like locking.
So... is/was j.l.management really the only way to solve this problem?
Wouldn't seeding with System.nanoTime also suffice?
Hmm... maybe a better solution is to stop acquiring a test lock
altogether? Only NativeFSLockFactory does this..., and it's actually
rather silly, because we acquireTestLock when .makeLock is called,
yet, the caller who called .makeLock will presumably shortly
thereafter call .obtain on that lock and will at that point see an
exception if there are issues with native locks on the current
Note that we are only trying to generate a unique name for the test
lock that the lock factory acquires to verify locking will work. As
far as I know, no app has ever hard a problem with this, ie, this is a
test-only problem. In fact, even reading through
LUCENE-2421 again, I
don't get why our tests are running simultaneous tests sharing the
same lock directory? Shai do you remember which specific tests cause
problems? And if the test lock was a problem, why then was the real
lock not a problem?