I can't guarantee that the code is 100% in compliance with java 3.0.3. All changes that could be ported have been ported in core and most contrib projects. There are a few things that should at least be discussed regarding the compatibility in core:
Occur (BooleanClause) in java is converted to an enum, from static readonly methods on a class. The reason that was never ported was because we can't override ToString() on an enum, even with extension methods and/or type converters. Currently, "MUST" evaluates to "+", SHOULD to "", and "MUST_NOT" to "-". I'd double check this, but I think that the ToString() on occur is only used when creating string representations of a query. So, in theory, we could replace the usages in that location, and make the conversion to enum. This isn't a high-priority, especially since the fields are static readonly, this likely doesn't affect performance much or at all. FuzzyQuery uses java.util.PriorityQueue<T> which doesn't exists in .NET. I think we wind up using a SortedList, which was just a temporary measure that I wanted to make sure was fixed before release. I've tried to subclass from Util.PriorityQueue<T>, but it breaks a few tests. The current setup with SortedList works fine, but it's slower O(n) instead of O(log n) I think for some actions, and it doesn't support duplicate keys...which is bad. SegmentInfos inherits from a thread-safe collection in java (Vector). We could have used SynchronizedCollection<T> and inherit from that, but I chose not to. I'm don't actually believe that lucene relies on the fact that Vector is ThreadSafe; instead, handling synchronization on its own. However, it's worth checking into, even though there are no tests that fail. Perhaps try to write one? IDK, there's a lot of multi-threaded tests, and I've yet to see a failure that's related to this. All intermittent tests that currently fail, do so for other reasons. Also, in this class, there are a few places where it should be returning a read-only HashSet, instead of returning a mutable one. =================== Open issues: I wanted to talk about the issues that are assigned, but just haven't had time. I think we really need to triage what is actually important and focus on that. I think I'll briefly just comment on a few of these and I hope to find out what you guys think of the open issues as well. I think can be moved to 3.5: ========================= LUCENENET- 439 - Correctly Rethrow exceptions in C# LUCENENET- 436 - Refactor Deprecated Code inside of tests LUCENENET- 435 - Fix the test suite for Lucene.Net Core (java lucene has refactored a lot of their test suite. I think this should be backlogged) LUCENENET- 467 - .NETify the public API where appropriate -- Some of this has already been done, but it's not critical to a release. LUCENENET- 456 - Create a Build Target that outputs compiled artifacts in apache release format These are of medium importance ========================= LUCENENET- 446 - Make Lucene.Net CLS Compliant -- The major issues with this have been more-or-less solved. The basic public API is almost completely CLS-compliant, except for usages of sbyte in FieldCacheRangeFilter and VerifyingLockFactory. Almost all classes can be used in other languages. There are 58 CLS naming issues, but most of them deal with protected members. If consumers were to use the library as is without customization, it's not blocking. However, it's not ideal to leave these issues in the release. LUCENENET- 337 - TokenAttribute for Selectively Including Tokens in Length Norm -- This is just a patch. I'm actually not sure what it does, so I haven't committed it to trunk because of that. High priority: These should be fixed or looked over before releasing ========================= LUCENENET- 484 - Some possibly major tests intermittently fail -- Obviously, we should try and have a test suite that consistently passes. There are only two that fail now, I think. LUCENENET- 493 - Make lucene.net culture insensitive (like the java version) LUCENENET- 490 - QueryParser is culture-sensitive -- These two above are fairly important. I don't know to what extent java lucene is culture insensitive, though, and until I do some tests, I don't want to jump in and start changing things. There are culture sensitive tests in the test suite, but they don't run because of JUnit and NUnit differences. LUCENENET- 470 - Change Getxxx() and Setxxx() methods to .NET Properties -- This is practically done. I think there are only a few places where this should be updated. I only put this in high priority, because the API changes between 2.9 and 3.x are the perfect time to do this. Almost all obvious ones have been changed already. There are a few others like [typename].Size() that could probably be changed as well, but those would have to be manually found. Other's opinions and insights are appreciated. Thanks, Christopher On Thu, Jun 14, 2012 at 8:58 AM, Prescott Nasser <geobmx...@hotmail.com>wrote: > > I'm going to try and review some of them - looking at the 3.5 ticket atm. > The code should be in compliance with 3.0.3. We might want to do some spot > checking various parts of the code. I'm not sure about the tests. Also, we > should probably run some code coverage tools to see how much coverage we > have. > ~P > > Date: Thu, 14 Jun 2012 18:37:12 +0300 > > Subject: Re: Releasing 3.0.3 > > From: ita...@code972.com > > To: lucene-net-dev@lucene.apache.org > > > > Ok, and is the code in 100% compliance with the 3.0.3 Java code? > > > > I'll be spending some time on fixing the index corruption issue, and it > is > > probably best for Chris to wrap up the work he has started > > > > Anyone else on board to close some tickets? > > > > On Thu, Jun 14, 2012 at 6:19 PM, Prescott Nasser <geobmx...@hotmail.com > >wrote: > > > > > > > > Agreed - > > > JIRA for 3.0.3 > > > > https://issues.apache.org/jira/browse/LUCENENET/fixforversion/12316215#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel > > > We should evaluate all of these - fix them, mark as won't fix, or move > > > them to another release version. I think the biggest hold up currently > is: > > > https://issues.apache.org/jira/browse/LUCENENET-484. Chris has made a > > > huge dent, but there are two test cases that are still listed as > failing (I > > > can't even duplicate those failures to know where to start) > > > Also we should look at all the other jira tickets and make updates > where > > > appropriate > > > ~P > > > > Date: Thu, 14 Jun 2012 13:21:04 +0300 > > > > Subject: Releasing 3.0.3 > > > > From: ita...@code972.com > > > > To: lucene-net-dev@lucene.apache.org > > > > > > > > Where do we stand with this? > > > > > > > > I want to push to a 3.0.3 release, what items are still pending? > > > > > > > > Itamar. > > > > > > > >
