I will apologize again for this post taking me forever to write.
When I converted the Apache project I ran into a fundamental or more precisely a philosophical problem; that, unfortunately, can not be fixed by the JLCA. The problem is whether it is better to keep to the original structure or migrate that structure to the .NET structure. While hierarchy differences are always some of the most difficult issues to resolve, this wasn’t an issue until I made it one. The Apache project was almost completely self-contained. The project had its own interfaces and super-classes. The problem was that I started to convert the classes that implemented (for example) Apache’s XMLDocument interface into classes that extended .NET’s concrete XmlDocument class. As you can imagine this caused a number of classes to now “have” multiple parent classes which I had to resolve, not to mention duplication of code (since Apache’s sub-classes had implemented the XMLDocument interface). This I kind of expected although it turned into more of a headache than I ever would’ve imagined. What I didn’t expect was the thousands of now incorrect virtual, overrides, and new keywords that the JLCA had inserted (assuming that I would continue to try and use Apache’s hierarchy) which I now had to fix. These were unbelievably tedious, and I came very close to not finishing the conversion a number of times. What makes these so bad is that they are easily covered by “real” compiler errors and so they seem to jump out at you continuously and make keep you from fixing all of them once and for all. Plus they have a cascading effect that goes down the hierarchy, so as you “fix” one, you break each of that class’s sub-classes. And so on, and so on…
I still believe (take this with a grain of salt since I am still a high-level “programmer”) that it is best to be as close to the bare-metal as possible. What I mean is that I would rather convert the XML libraries to use .NET’s built-in support than re-implement this myself (or use Apache’s implementation of it). But this did end up making a lot more work. I have to admit that the JLCA does not handle this aspect of conversion very well. The JLCA tries its best to keep the exact form/function of the Java code which, in this case, was at odds with what I wanted my C# code to be. I think this is a rather extreme example of this problem since all of Apache’s XML functionality is present in .NET’s XML libraries so just about every class I ran into had to be changed to accommodate this. What I ended up with is a programmatic interface that pretended to mirror Apache’s XML interface on top of .NET’s XML libraries. This would’ve been a lot faster to just implement this interface from scratch instead of pruning all of the original Java implementations out of the migrated code one at a time. I actually created almost an exponential growth of errors as I went about my restructuring!
While I can justify this as a great experiment that I learned a lot doing (I love my job!), from an Enterprise view this should stand as a warning. The JLCA, or any tool for that matter, is just that: a tool. If, at any point during the migration, you find that you are in a similar situation (exponential error growth, cutting massive amounts of the old Java logic that is now covered in .NET, …) you should stop and re-evaluate if it wouldn’t be easier to start writing C# from a blank file. This isn’t to say that you have to choose one path or the other, if I was writing a real Enterprise application that happened to use this set of Apache’s libraries I could easily convert the rest of the application with the JLCA and only implement a similar interface on top of .NET’s libraries as I suggested above (or you could migrate the rest of the app and then modify the calls that use to use Apache’s libraries to use .NET’s and cut the interface out completely.)
I would like to point out that I am not saying the JLCA is not useful, just that it isn’t the only option and, although it pains me to admit, it is not always the best option. Besides rewriting there is also J#, interoperability, and other 3rd party tools that could be used instead or in addition to the JLCA. The idea is to choose the right approach for your situation. This is an aspect that I don’t think a lot of people think about; especially the J# option. J# has full access to the .NET platform and the J# DLLs work just as smoothly with a C# project as any other .NET DLL. Areas of your application that limit themselves to the JDK 1.1.4 functionality or just fit within J#’s domain would be converted at almost 100% instead of the JLCA’s 85-90%. This could save you a lot of time by converting component of you application individually with whichever tool was easiest. I think that I will try to focus the next couple of posting on this aspect of conversion instead of the more technical issue-fixing side. Hopefully I will be able to get back into my weekly posting schedule again!
