Just keen to know why you felt a c# port was better than a J# recompile of lucene?
Is it just performance-related? Do you have figures for relative performance?
You obviously create a lot of work for yourself in having to maintain a handcrafted C# version of the main lucene codebase.
The answer is very simple. C# - the leader of .NET
so J# or Visual Basic are not so interested for us.
It,s my personal opinion: VB and J# are supportable languages. They are used to make easier a way of working with .NET technologies for peaple who have deal with VB or Java before.
As for creating a lot of work - NLucene is not a port of Lucene, to make sure of it just look into the code. It,s a .NET/C# implementation of Lucene from the beginen. It was our goal.
>>J# are not so interested for us.
But isn't the point of .net to make it irrelevant what language the classes were written in?
Having seen the lucene java codebase compile and run as a J# project without a single code change I'm unsure as to why you felt the need to rewrite it by hand in C#. Surely you could call a compiled J# version of lucene from whatever .net language is your preference?
I have heard that in order to make Java code compile cleanly as J# there are "wrapper" classes for common .net core classes to make them look like common java core classes (eg java.util.HashMap) so I could see a reason why performance may be a concern for J# but I do not understand why you claim to have based your decision purely on a language preference (C#).
If I'm right in assuming you do not have automated java to c# conversion tools nlucene will always lag behind the Java implementation, waiting for you to manually convert the latest codebase.
>But isn't the point of .net to make it irrelevant >what language the classes were written in?
May be, but the answer is very simple again.
An every language has a style so called features
My personal opinion: there is still a lot of diffs between Java and С#. Moreover it's a fact.
NLucene isn't just a tool but this is search and indexing API.
I believe that API MUST be the same style as a language but it's up to you.
Sorry but I know what lucene is and Lucene Java style doesn't suit me when I do something in C# (Java is another story.)
There are a lot of jakarta projects re-made in .NET
Avalon # (I created it more that year ago and now it's hosted in Jakarta Avalon Project)
cause people can intoduce new features and new possibilities and so on...
>Having seen the lucene java codebase compile >and run as a J# project without a single code >change
Compiling and running mean nothing to me.
I think you agree with me.
What kind of tests did you do?
What were the performance?
Can you share your result?
>I have heard that in order to make Java code >compile cleanly as J# there are "wrapper" classes >for common .net core classes to make them look >like common java core classes (eg >java.util.HashMap) so I could see a reason why >performance may be a concern for J# but I do not >understand why you claim to have based your >decision purely on a language preference (C#).
The Performance is the answer.
NLucene works faster than Lucene does.
You can make tests and make sure of it.
I get the impression we may be talking about different things...
>>NLucene works faster than Lucene does
That wasn't my question (if you mean comparing Lucene on a JVM versus NLucene on .net runtime)
I was asking if you had compared performance of a J# compiled version of Lucene with your C# ported version, both running in a .net runtime.
As a potential C# developer wishing to call search and indexing APIs I'm also keen to understand what the differences are in the interface provided by your C# classes and those of a J# compiled version of Lucene? You seem to suggest there are benefits in the "style" of your C# version.
I dont mean to be antagnostic - I'm just trying to understand your motivations better :)
>I dont mean to be antagnostic - I'm just trying to >understand your motivations better :)
and you did tenacious efforts to wonder :))
We did it cause we needed a C# solution (not J# and so on ...) and then we had to integrate it as a background into our API. (I hope you could undestand why style was so important as well.)
There wasn't one, so we decided to make it.
>I was asking if you had compared performance of >a J# compiled version of Lucene with your C# >ported version, both running in a .net runtime.
No, we didn't and personally it's hard to believe for
me, that Lucene J# is OK. Nevertheless,
I'm deadly sure that NLucene indexing process works much faster that J# Lucene cause we wrote our own Lexer/Parser not JavaCC generation code.
cause there wasn't any R-L-K in .NET at that time.
About searching process I can't give you the answer but
I'm eager to look into and test J# Lucene and how J# works with JavaCC code generation and I will do it definetely this week-end and then we can talk more detail.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.