This isn't so much about systems interop, as it is about code re-use and language interop. You've seen Sudoku, the "number place" puzzle. Wikipedia says that it was created by a US puzzle magazine, but popularized (and given its recognized name) by the Japanese.
Re-use of existing Java code (Sudoku engine)
This isn't so much about systems interop, as it is about code re-use and language interop.
You've seen Sudoku, the "number place" puzzle. Wikipedia says that it was created by a US puzzle magazine, but popularized (and given its recognized name) by the Japanese.
Last year during the summer holiday my wife gave me a book of Sudoku puzzles to do on the beach with my kids. The first one we tried was a real challenge, but gradually we caught on to the technique. Now we do the puzzles that come in the daily paper, regularly. They started to get a little too easy for us, so our thought was, maybe we could generate puzzles ourselves?
I thought - this is a nice little programming project. The next thought was: to generate a valid Sudoku, you have to solve it, to verify there is only one solution. The simple brute force solver method I imagined would be easy to code, but wouldn't be very fast. And I hadn't thought about sudoku generation algorithms. This was getting messy. Maybe somebody has already done this for me?
In short order I found lots of Sudoku sites and an abundance of algorithms and code implementations for generators and solvers. I tried a couple and found one that looked good and fast - implemented in Java by Rolf Sandberg, based on a C implementation by Günter Stertenbrink, which was based on the Dancing Links algorithm described by Donald Knuth.
As a port from C, the Java code is not the most object-oriented or elegant, but I didn't care about that. I wanted a toy to generate Sudoku puzzles. It worked great, but there was one big drawback. The generated puzzles looked like this:
. . 8 1 . . . . .
. 9 1 . . . . . 7
. . . . 5 . 3 . 2
6 . . 3 . 2 8 . 4
3 . 9 . . . 5 . .
. . . . . 6 . . .
. 1 . . . . . 2 8
. . 6 . . . . . .
. 5 . . 7 . . . .
It was a command line tool, and it generated string output. What I really wanted was a puzzle I could print out, easily, and hand to my sons and say "have at it!"
I had previously fiddled with itextsharp, a library for creating PDFs from within .NET. (This is a port of iText, which is a Java library with the same purpose). PDF generation would seem to be a good fit.
Here Comes the Part About Interop
The cool thing was, I didn't have to do anything to the Java code to get it to work with my C# WinForms code. I just compiled it with VJ#, and BAM! it's ready to go. So no changes were required, but I did actually make a few changes in Sandberg's Java code. I added a DTO class for the puzzle. I added a few helper methods like solve() and generate() and rate(). But I left most everything intact. (re-factoring was tempting but I didn't want to spend the time understanding the code)
So.... I built a Winform app in C#, to wrap around that generator engine. I added in the PDF generation, and added a print button. Boom, a Sudoku generation toy. Its pedigree includes Java source code, C# code, and an activeX control from 2000. All seamlessly connected.
Grab the finished binary (with a Windows Installer) if you want to use the toy. It will run on Windows XP, requires .NET 1.1 and Adobe Acrobat Reader. Grab the VS 2003 Solution if you want to examine or tweak the code.
This is just one small illustration, but it shows: if you have source code repositories in your shop, or even if you have existing Java apps, and you want to update or extend them, you may be able to re-use that code very simply in .NET.