Archive for the ‘Java’ Category

When should ports go native?

December 2, 2005 3 comments

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 “” which will find all
secrets containing various spellings of (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

David Patton presents Agile .NET to an XP audience

April 14, 2005 Leave a comment

David Patton gave a presentation at the Washington DC XP User Group on Monday night. It was different to the typical XP/TDD presentation due to the audience (who needed no introduction to TDD!) and also David’s experiences. It was interesting to hear the audience’s surprise at the maturity of the tools for Agile development on the Microsoft platform and also tohear the comparisons to tools on other development platforms.

Some of the things that drew gasps from the audience:

  • UsingNUnit attributes to label test fixtures and test cases freeing you from naming conventions or inheritance to define tests. (Example: jUnit requires TestFixtures to derive from TestCase and test cases to be prefixed with “test”)
  • [Ignore] attribute to ignore a currently failing test while giving some legitimate reason to explain, then seeing NUnit show this as an ignored test. (Example: Many developers on other platforms would just prefix the test case with an underscore to have it ignored and then might forget about thetest)
  • [TestFixtureSetUp] attribute enabling setup code to be executed once for a whole fixture. Apparently this is an often desired feature missing from other platforms.

What do you like or dislike about the agile tools on the .NET platform versus other development platforms?

C# – NAMED LOOPS … I miss them.

October 12, 2004 4 comments

Named loops give the ability to extend flow control with markers. Cynics would argue they are glorified gotos but in that case, they probably don’t like continue anyway!

Here is a simple contrived example:

1namespace NamedLoopExample 
3 public class NamedLoops
4 {
5 public void Example()
6 {
7 Product[] products = new Product[] { new Product() };
8 Sku[] skus = new Sku[] { new Sku(), new Sku() };
9 // in Java: ProductLoop: for (int n = 0; n < products.Length; n++)
10 for (int n = 0; n < products.Length; n++)
11 {
12 for (int i = 0; i < skus.Length; i++)
13 {
14 // find the right sku
15 // continue with the next product not sku
16 // in Java: continue ProductLoop;
17 }
18 // some other logic to do something else
19 // since the sku wasn't found
20 }
21 }
22 }
23 public class Product { }
24 public class Sku { }

Named loops are not something you need very often, but occassionally they are useful. The alternative of tracking a bool to know when to break is really ugly. Often you can refactor the logic possibly into separate methods (with Extract Method) to make the flow easier to manage.

Does anyone else miss named loops?

UPDATE (10/13/2004): There is a great discussion of GOTO that also references named loops on the C2 wiki.

Categories: .NET, Java

Xml documentation comments are like hairspray!

February 14, 2004 3 comments

The Refactoring folks talk about CodeSmell and CodeDeodorant. The concept is that a codesmell is when there is a feeling that something *could* be wrong with a piece of code. CodeDeodorant is when an attempt is made to cover up the smell by adding whitespace (for “clarity”) or detailed comments to explain the code. These are usually signs that the code needs improving …

The arrival of automatic documentation tools like Javadoc and NDoc often triggers animpulse to generate reams of HTML documentation for your API. However,documentation comments suffer from the same drawbacks as comments in the code:

  • They are not executed and therefore could contain errors or could be out of date.
  • They are also a burden and time drain to keep updating as your API evolves.

Ifyou are following TestDrivenDevelopment(TDD) then you already have a complete set of unit tests that exercise all the features of your code.What better examples could you provide for your API then a full set of passing unit tests?

In conclusion,TDDmakes XML documentation comments like hairspray. Nice to look at, a pain to modify and certainly not essential! :-)

Disclaimer: If your customer agrees that a documented APIbrings business value or your API will be published to developers without a source code release, then by all means generate documentation.

Thanks to Jason Alexander from the nGallery team in helping formulate this idea.

Sun's JVM gets *seamless* NTLM support in soon to be released 1.4.2_02!

August 29, 2003 Leave a comment

Microsoft has dropped support for the Microsoft VM and this leaves applets in an uncertain position.  Sure, you can just install Sun’s JVM but it won’t work on your Microsoft IIS-based intranet if you are running NTLM.  I have seen this problem at several clients where “single sign on” is essential and NTLM is the mechanism in use.

Here is the bug fix report on (free registration required).

This will keep the door open for technologies such as Microsoft’s Remote Scripting from ASP which use a hidden applet to make calls back to the server.  I have played with non-applet based approaches to invoking Remote Scripting such as one based on Brent Ashley’s JSRS but I never could get the synchronous calls to work.

Roll on 1.4.2_02 !

Categories: Java

Get every new post delivered to your Inbox.