C to Java

I’ve almost finished the mostly-mechanical first pass of converting the C GNU Chess code to Java syntax. I haven’t tried to compile yet, but there’s about six files out of thirty-plus that IDEA (world’s greatest IDE) says contain syntax errors. Most of them are complicated printf() calls that I put off, thinking I might just start using Java 5, which comes with a printf() of its own. Also remaining are some threading issues like the use of the signal() function.

The most common C features in C GNU Chess that needed converting to Java:

primitive typedefs
better readability and type-checking by using BitBoard instead of long. I started using Java classes for these typedefs, but BitBoard operations much be fast, and I’ve have to deal with translating between the different semantics for assignment of primitives and objects.
most were just constants; I made functions for most of the others, except a few like CLEARBIT that seemed easier to inline.
primitive reference parameters
I used the return value if possible; otherwise I passed the params in an array.
printf and scanf
only a few of these we hard to convert; Java 5’s printf will help
something else that’s available in Java 5
implicit bools
I can’t count how many times I converted “if (c)” to “if (c!=0)
Java doesn’t have goto, but it does allow labels on break and continue, which sometimes resulted in creating dummy loops just so I could use a labeled break instead of a goto.

Java Port of GNU Chess

A week or two ago I started porting GNU Chess from C to Java in my spare time. The main motivation is to refresh my Java skills after two years of C++ immersion. It’s amazing how quickly you can lose the subtleties of a tool when you don’t use it.

I’m sure the project will succeed at making we aware of the Java/C differences, but I have to admit it’s unlikely the port will produce a runnable chess-plaing program even if I stick with it. GNU Chess code is pretty hairy, especially since it sacrifices clarity for speed. But if it does by chance run, it will serve as an interesting Java benchmark and will give me something to tinker with.

So far I’ve been translating each file to a Java class composed of static members, and I’m probably about 15% done by volume. The biggest headache so far has been lexpgn, which is a PGN (Portable Game Notation) file parser that is generated from a grammar description, sort of like ANTLR but different. I’ve barely used ANTLR, but if I knew it well, the thing to do would be to translate the lexpgn grammar to ANTLR syntax directly. The main lex() function is 800 lines long with nested switch statements and gotos …