views:

320

answers:

7

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!

+1  A: 

I am not sure if this even is an option for you, but you might want to consider developing in Java and then converting the jar files to .NET assemblies using IKVM. I haven't used it for few years, but back then it was working pretty well.

Bogdan
A: 

This product could be useful for you:
http://dev.mainsoft.com/Default.aspx?tabid=130
Hope this helps.

Jaime Febres
+1  A: 

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.

Jon Skeet
A: 

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.

Peter Tate
+2  A: 

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.)

Jared
A: 

If they are so similar is there any real advantage in maintaining both versions? Maybe you could ditch one of them...

Jim Arnold
A: 

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?!

Paul Morrison
It's sort of related, but I think it's different enough that you should ask a new question. The idea is to edit the question instead of adding an answer that's not an answer (like this), but if it doesn't belong in the question, that's a good clue that it's time to ask a new one.
Michael Myers
I thought I ought to close the loop on this... This problem was due to the fact that #develop 2.2 forces TortoiseSVN 1.4 - it does not work with TortoiseSVN 1.5. I had to give up on using #develop. Visual C# Express works well enough for my purposes, and I use Tortoise SVN with Windows Explorer.
Paul Morrison