Github user NightOwl888 commented on the issue:
https://github.com/apache/lucenenet/pull/191
> > There are 2 different PriorityQueue types in Lucene.Net
> Is there a reason for this? Can we stay with one?
Yes, there is a reason for that â that is the way it is done in Lucene.
As for sticking with one I am not sure. The one the Lucene developers came up
with seems much more specialized than the one in the JDK, which is what our
Support.PriorityQueue is a close match for.
I noticed that there were modifications to the Util.PriorityQueue that were
not in Lucene (namely adding a default constructor and functionality to make it
growable). There were also major differences in the unit tests (I ported the
original tests over, but left the extra ones in place). I was hoping this was
the cause of the null reference exception in one of the tests in Misc, which I
know can be fixed by simply making defensive coding against null, but I was
hoping to uncover and fix the root cause. Unfortunately, the Util.PriorityQueue
does not seem to be it. But it seems Connie has already resolved it on this
branch.
I also noticed that [Core.Search.TopTermsRewrite is referencing the wrong
PriorityQueue](https://github.com/apache/lucenenet/blob/master/src/Lucene.Net.Core/Search/TopTermsRewrite.cs#L287).
I have it corrected here on a local branch, but havenât yet run tests on it
to see what the total impact is (that particular class doesnât have any unit
tests). I suspect there are other places where the wrong PriorityQueue is being
used, which could affect the stability of those pieces.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
