lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Currens (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENENET-480) Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
Date Thu, 14 Jun 2012 19:02:43 GMT

    [ https://issues.apache.org/jira/browse/LUCENENET-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295239#comment-13295239
] 

Christopher Currens commented on LUCENENET-480:
-----------------------------------------------

I'm assuming we're going to define some sort of symbol to compile code if it's 3.5 vs 4.0.
 If so, we can do a few things to make it easier.

1. We can.  The only reason we're using the interface is because Java is.  I can see in the
future this might be a problem if we has to use a set class that was not HashSet...but at
least not it's not a problem.  Alternatively, we can write our own ISet class based on the
.NET 4.0 one, and use a class that wraps HashSet and implements ISet.
2. I think the only way to do this one is write our own, as you said.
3. We can just define these in the support class, when using .NET 3.5
{code}
public delegate TResult Func<T1, T2, T3, T4, T5, T6, T7, T8, T9, TResult>(T1 arg1, T2
arg2, T3 arg3, T4 arg4, 
                                                                          T5 arg5, T6 arg6,
T7 arg7, T8 arg8, T9 arg9)
public delegate TResult Func<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, TResult>(T1 arg1,
T2 arg2, T3 arg3, T4 arg4, 
                                                                               T5 arg5, T6
arg6, T7 arg7, T8 arg8, T9 arg9, T10 arg10)
{code}
4. We can either use Digy's (I think it uses a WeakHashTable) or we can write our own (more
work), using Thread.AllocateDataSlot().  I believe that is how it is done internally in .NET
4.
5. ParallelMultiSearcher does have the biggest changes between .NET 3.5 (and actually Java's
version of the class, because of the use of Tasks instead of manually spawning threads). 
I feel like we could remove it from the 3.5 version (at least for now), or have two versions
of 3.5, where one has a dependency on the TPL for 3.5.
                
> Investigate what needs to happen to make both .NET 3.5 and 4.0 builds possible
> ------------------------------------------------------------------------------
>
>                 Key: LUCENENET-480
>                 URL: https://issues.apache.org/jira/browse/LUCENENET-480
>             Project: Lucene.Net
>          Issue Type: Task
>          Components: Lucene.Net Contrib, Lucene.Net Core, Lucene.Net Demo, Lucene.Net
Test
>    Affects Versions: Lucene.Net 2.9.4, Lucene.Net 2.9.4g, Lucene.Net 3.0.3
>            Reporter: Christopher Currens
>
> We need to investigate what needs to be done with the source to be able to support both
a .NET 3.5 and 4.0 build.  There was some concern from at least one member of the community
([see here|http://mail-archives.apache.org/mod_mbox/lucene-lucene-net-dev/201202.mbox/%3C004b01cce111$871f4990$955ddcb0$@fr%3E])
that we've alienated some of our user base by making such a heavy jump from 2.0 to 4.0.  There
are major benefits to using 4.0 over the 2.0-based runtimes, specifically FAR superior memory
management, particularly with the LOH, where Lucene.NET has had major trouble with in the
past.
> Based on what has been done with Lucene.NET 3.0.3, we can't (easily) drop .NET 3.5/3.0
libraries and go back to 2.0.  HashSet<T> and ISet<T> is used extensively in the
code, that would be a major blocker to get done.  I suppose it could be possible, but there
hasn't been a whole lot of talk about what runtimes we intend to support.  The big change
between lucene 2.x and 3.x for java was also a change in runtimes, that allowed generics and
enums to be used in the base code.  We have a similar situation with the API (it's substantially
different, with the addition of properties alone) for this next version of Lucene.NET, so
I think it's reasonable to at least make a permanent move from 2.0 to 3.5, though that's only
my opinion, hasn't been discussed with the committers.
> It seems that supporting 3.5 and 4.0 should be fairly easy, and is a decent compromise
in supporting both a 2.0 and 4.0 runtime.  At the very least, we should try our best to support
it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message