可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

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:

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

回答2:

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.

回答3:

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.

回答4:

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.