Hi Nick, Doing an initial port is very challenging and time consuming because it's not totally automated. I have relied on JLCA and automated scripts that I wrote to do ports (going back to 1.4 days). The reaming issues that you see now are minor compared to what JLCA leaves you with. I have posted a couple of times about this, so search the mail archive for the details.
Basically, an initial port depends heavily on deltas between two release (deltas both in the Java Lucene and Lucene.Net world). Thus, if we start taking full advantage of what .NET and C# has to offer, unless if we are first at a commit-by-commit level with what's happening in the Java Lucene world, we can be in a total mess when the next release arrives. So, before we can achieve this, we need 1) release closer to Java Lucene releases (I hope 2.9.1 and 3.0 will be it), 2) we need more Lucene.Net contributors and committers who are active. Thanks. -- George -----Original Message----- From: Nicholas Paldino [.NET/C# MVP] [mailto:casper...@caspershouse.com] Sent: Tuesday, November 10, 2009 12:30 AM To: lucene-net-...@incubator.apache.org Cc: lucene-net-user@incubator.apache.org Subject: RE: 2.9 Target Framework Michael, Sorry for the newb question, but what are the issues in moving to .NET 3.5 now (I just joined the list today and am looking around in the archives now, btw)? In the move from .NET 2.0 -> 3.5, the CLR was not changed. The only things that were changed were BCL types (base class libraries, and they are backwards compatable), and the compilers (to allow for lambda expressions, anonymous types, query syntax, and the like). The reason I ask is that in doing my own port of Lucene.NET 2.0 to a .NET 3.5 implementation, I've found that there are a number of helpful constructs, some of them being: - Hashset<T> - LINQ allows for the flattening of a number of nasty embedded loops, and a more declarative style of code. - Lambda expressions Among many others. If the concern is alienating a user base that is on .NET 2.0 and can't move to .NET 3.5, then that settles it, but if it is a concern over one of the items mentioned above (changes in the CLR, BCL), then I'm not sure what the concern is (not saying that there isn't one, but looking through the archives, I can't find the particular discussion around this topic). The reason I question this is because when working on my port, I figured it would be better to just contribute to the project itself. However, I feel I can be of more use in getting the internals correct, and .NET 3.5 would really help with that (there are a number of issues revolving around synchronization, enumeration usage which are not best practices). While internals can be changed for a move to .NET 2.0, for a lot of the places where you are going to integrate .NET 2.0 code, you are probably going to want to use .NET 3.5 code to even further simplify and enhance the code. A perfect example is a number of the loop iterators that you have now over ArrayList instances. At the least, those instances should be strongly-typed IList<T> implementations (typically List<T>) especially when the type parameter T is a value type. When a value type, the performance of using an IList<T> implementation over an ArrayList is somewhere around 40%-50% faster than using ArrayList (because of lack of boxing). When a reference type, there is still a performance gain (I think it was around 10%-20%, but don't quote me on that one). This is all Generics, and I assume everyone knows the benefits of moving to them. When doing so, that causes a chain reaction. In moving to an IList<T> implementation, you have an IEnumerable<T> implementation and you will want to replace a lot of the iterator code from for loops to foreach loops (which you can use in .NET 1.1, I don't know why they weren't used, you still had the runtime cast issues). However, most of these loops have some sort of filtering/sorting/grouping logic. LINQ really goes a great way to simplify the code in this situation, separating the logic of what you want to do from the items you want to do it to (or even creating the appropriate projections to assist in what you are trying to do, I've used it in a number of places to flatten some pretty nasty embedded for loops quite efficiently). The point is, if you go to .NET 2.0, you get yourself part of the way there when it comes to how much you can do to improve the codebase (and I am speaking only of the internal implementation, I'm not suggesting you change the public definition of the class) and will eventually require a revisit to the same code. Given that you have the test cases already, what's the harm (assuming it isn't a user base issue) in going to .NET 3.5 now, and reaping the benefits now if a number of files are going to be touched because of the move to .NET 2.0 anyways? - Nick -----Original Message----- From: Michael Garski [mailto:mgar...@myspace-inc.com] Sent: Monday, November 09, 2009 11:20 PM To: lucene-net-user@incubator.apache.org Cc: lucene-net-...@incubator.apache.org Subject: RE: 2.9 Target Framework No problem - 2.0 it is. Michael -----Original Message----- From: George Aroush [mailto:geo...@aroush.net] Sent: Monday, November 09, 2009 7:16 PM To: lucene-net-user@incubator.apache.org Cc: lucene-net-...@incubator.apache.org Subject: RE: 2.9 Target Framework I agree with DIGY. We have discussed this in the past few times. We have to get 2.9.1 out really soon, so we can catch up with 3.0 and do more than just port over logic from Java to C# -- but also take advantage of what C# and .NET has to offer. BTW, those kind of discussions should be on the dev side vs. user. -- George -----Original Message----- From: Digy [mailto:digyd...@gmail.com] Sent: Monday, November 09, 2009 1:19 PM To: lucene-net-user@incubator.apache.org Subject: RE: 2.9 Target Framework I think we should stick to .NET 2.0 till Lucene 3.0 which can be a good place to switch to .NET 3.5 (so will Lucene.Java do also). There are also a lot of places where smarter codes can be used ( replacing "GetEnumerator+while" with "foreach", implementing a .NET like "Set" instead of using Hashtable etc.) But it can be a problem in porting unless we catch up with Lucene.Java. DIGY -----Original Message----- From: Michael Garski [mailto:mgar...@myspace-inc.com] Sent: Monday, November 09, 2009 7:26 PM To: lucene-net-...@incubator.apache.org; lucene-net-user@incubator.apache.org Subject: 2.9 Target Framework Apologies for the cross-posting to both lists, but I think this issue is applicable to both. What is the target framework for Lucene.Net 2.9? I'm assuming 2.0 but would like to ensure this is defined. There are a few cases in some of the internal implementation where use of LINQ would be handy, such as in collection transformations to arrays. Overall, it's not a big deal to target 2.0 however some of the implementation will be a bit more elegant and precise if we target 3.5. Cheers, Michael Michael Garski Sr. Search Architect 310.969.7435 (office) 310.251.6355 (mobile) www.myspace.com/michaelgarski
