I am maintaining two very similar schedulers - one in Java and one in C#. The C# version was originally created using JLCA and then modified by hand. The Java version has been modified quite significantly over the last few weeks by someone else (so I have to track down his changes), and I am wondering whether to reconvert it using one of the tools available on the Internet, or whether to just try to make the changes by hand each time the need arises. This problem may well come up frequently for me - is there some way to maintain versions of software in two different languages and keep them in step as painlessly as possible?! Suggestions would be appreciated!
This product could be useful for you:
http://dev.mainsoft.com/Default.aspx?tabid=130
Hope this helps.
I would personally maintain the differences by hand. This means that if at some point it makes more sense to do something differently in .NET (which may well be the case, in order to make the code idiomatic) you don't need to keep reapplying that change manually.
Another option is to do the conversion of the original Java code, copy it, then do the conversion of the modified Java code. Diff the results of the two conversions, and apply that change to your existing code where it can be done simply. That saves you from doing "gruntwork" conversion while keeping your existing code.
Have you considered J#?
Depending on your needs and configuration you can cross-compile your Java code as both Java and J#. You may need to refactor the common parts into a seperate module will compile in either environment (J# is stuck at Java 1.2, with a few 1.3 classes).
Keep in mind that J# is old, and no longer available in VS 2008 (you'll need an old copy of Visual Studio 2005), however depending on the complexity of you project this might be a workable solution.
I've had very bad experience using off-the-shelf code converters to maintain projects in two different languages (note that I didn't say to convert, I fully believe that doing an initial conversion/cleanup with an automated tool might have merit.)
There are people who support multiple platforms regularly, and they love to point out the pains of language selection without their own in-house tools, but they tend to use specialized languages or bind themselves to a set of language constructs by convention, so that their intermediate compilers can do the grunt work for them.
Short of some cool proprietary cross-compiler, and the code conventions that go with it, I'd do the work by hand. The trick will be tightly monitoring checkins, and ensuring that the functionality gets checked in both places. Depending on how severe the problem is, you could invent a source control process (that could range from oppressive and painful, to relatively light weight) that could help guarantee this (for example, you could require developers to check in changes only to a branch until the port is done on both platforms, at which time you merge them both.)
If they are so similar is there any real advantage in maintaining both versions? Maybe you could ditch one of them...
Sorry, I am not sure where to put this question - it is sort of related to this thread... Comments don't seem to provide enough room, and don't seem to be as visible as questions...
I think I am having version problems because I have Subclipse installed for Java and just installed TortoiseSVN for #develop, as suggested by someone answering another question of mine. When I try to edit a C# class, it says "client is too old to work with working copy" - but the Subversion version of TortoiseSVN seems to be newer than that of Subclipse. What is going on?! Can I downgrade the version level of TortoiseSVN to match Subclipse, or upgrade Subclipse?!