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 Sun, 17 Jun 2012 21:22:42 GMT

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

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

I would feel most comfortable leaving it as ISet<T> in most (all?) places, based on
the one you've created, which I'm assuming follows the same contract as .NET 4?  I can see
Java possibly using more and more classes that aren't HashSet, that implement ISet.

What did you wind up doing with SortedSet, did you write a class for it?
                
> 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