Home > .NET, Java, Software Development > When should ports go native?

When should ports go native?

Our product, Secret
, uses the DotLucene
for searching of items (“secrets”) in
the application. DotLucene is an impressive API which creates index files
on disk based on the data you feed to it. It then allows for some very
powerful text searches to find data such as “amazon.com~” which will find all
secrets containing various spellings of amazon.com. (Moreinfo

The DotLucene API is, as you might have guessed, a
port of the Java Lucene search API and herein lies the problem. Lucene is
written in Java and therefore the API has a Java flavor to it. This makes
it harder and less intuitive for a native .NET developer to use.

To index a secret, we use:

  1 IndexWriter writer = new IndexWriter(_indexLocation, new StandardAnalyzer(), false);
  2 Document document = new Document();
  3 document.Add(Field.Text("Name", secret.Name));
  4 document.Add(Field.Text("Created", secret.Created.ToShortDateString()));
  5 document.Add(Field.Keyword("Id", secret.Id.ToString()));
  6 writer.AddDocument(document);
  7 writer.Optimize();
  8 writer.Close();

A typical .NET developer would probably expect
IndexWriter to implement IDisposable but it doesn’t. How do we ensure the
file is closed should an error occur while indexing?

Our problem was figuring out how to reindex a
“secret”, simply adding it creates duplicates in the index.

  1 IndexReader reader = null;
  2 try
  3 {
  4 	reader = IndexReader.Open(_indexLocation);
  5 	reader.Delete(new Term("Id", secret.Id.ToString()));
  6 }
  7 finally
  8 {
  9 	if (reader != null)
 10 	{
 11 		reader.Close();
 12 	}
 13 }

The solution is to use the IndexReader (?!).
Yes, not very intuitive. This can’t really be attributed to a “language
style” issue since a Java developer probably wouldn’t expect this

I have talked about language style beforebutporting an API has even more issues.NUnit
broke away from their Java porting heritage in 2.1 by
rewriting it to use custom attributes instead of jUnit’s naming conventions for testfixtures and
tests. This had many benefits since they could produce a more elegant
design that would harness the power of the .NET platform and it would be more in
the style of typical .NET APIs. These benefits come at a cost however
since anyone familiar with jUnit can no longer easily transfer their knowledge
to NUnit.

It also means that many other areas of knowledge
from the original API are not always useful for the native port:

  • Newsgroup posts
  • Online documentation
  • Tutorials

When does it make sense to go native with a
port? Is going nativea sign of maturity for an

Jonathan Cogley isthe CEO and founder of
thycotic, a .NET consulting company and ISV in Washington DC. thycotic has
just released
Thycotic Secret Server which is a secure web-based solution to both “Where is my Hotmail
password?” and “Who has the password for our domain name?”. Secret Server
isthe leader in secret management and sharing within companies and

  1. http://
    December 2, 2005 at 7:03 pm

    Well, to be fair, the Lucene API in Java doesn’t win a lot of awards for elegance, either. Ideally someone should fix the API in both languages in this case.

  2. http://
    December 2, 2005 at 7:30 pm

    Um, yeah, that’s what he’s saying… Lucene.NET is an almost direct port of Lucene Java’s API.

    Anyhoo, ther’s very few APIs out there that actually don’t suck. Writing a decent API is very, very hard and beyond the reach of most programmers.

  3. Alex Lindgren
    December 7, 2005 at 4:33 pm

    I used Lucene.NET for a project about 2 years ago. I probably wouldn’t have used it had I not been programming in Java previously. At the time, I was more familiar with Java than .Net (and even then, as someone pointed out the Java APIs aren’t pretty). I’m glad to see that people are still maintaining ports for it and that there is more documentation (and a new website!) then there was. I think that is what’s most important. Ideally, it would have a more standard .net like API but I imagine that would be harder to maintain and more likely to diverge from the Java project.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: