将项目从 C# 迁移到 Java
https://stackoverflow.com/questions/740625
-
09-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
随着办公室人员配置的一些变化，C# 专业知识水平急剧下降，现在有更多的 Java 开发人员。高层正在考虑将现有的用 C# 编写的 .NET 项目迁移到 Java 世界。
除了显而易见的问题之外 完全从头开始 该公司可以通过哪些方式成功地将项目开发从 .NET C# 迁移到 Java？
解决方案
以下是需要考虑的事项：
- 这是一个大工程吗？如果是，请尝试坚持使用 C#
- 这是一个带有组件的中型项目吗？如果否，请尝试坚持使用 C#
- 这个小项目只能部署在windows上吗？如果是，请尝试坚持使用 C#
- 这是旧的源代码吗？如果是，请尝试坚持使用 C#
- 您使用 Windows 操作系统特定的 API 吗？如果是，请尝试坚持使用 C#
- 您是否使用任何没有 Java 对应项的第三方 API？如果是，请尝试坚持使用 C#
- 您是否在“深度”（数据绑定、用户控件等）中使用.Net？如果是，请尝试坚持使用 C#
- 迁移时间比聘请新的/转换的 C# 人员更容易接受？如果不是，请尝试坚持使用 C#
- 如果您使用Java框架来改变表现形式，您是否认为最终用户不会接受变化？如果是，请尝试坚持使用 C#
- 检查广告
如果您决定转换：
- 按组件进行
- 每层走一遍
- 有很多测试
- 检查是否有工具可以帮助（无论帮助可能很小）迁移
其他提示
我想补充布赖恩和Eric的意见，我会说，拿起C＃为Java开发人员应该在我看来简单。在概念上是非常相似的语言，我会建议你训练的Java开发人员获得一些C＃技能，这样你就不会被强迫去迁移过程中的麻烦。
我同意乔尔的观点 完全重写几乎总是一个错误. 。其他海报是正确的：C# 和 Java 非常相似，任何有能力的 Java 开发人员都应该能够在几周或几个月内掌握 C#。这并不是说他们会成为专家。这需要更长的时间，但只要您有一些 C# 开发人员可以指导该过程，那么您应该没问题。
在不了解您的应用程序的具体情况的情况下，很难评论这种转变是好是坏：规模、应用类型、行业等。
我对这样的转变非常谨慎，因为以我的拙见， C# 现在是一种比 Java 更现代的语言 我是作为一个已经从事 Java 开发十多年（从 1.0.2/1.1 开始）的人向您说这些的。
这并不是说 Java 不好。它不是。Sun确实有一个阴云笼罩着它，并且近年来表现出不愿意或无能力推动该平台向前发展。
不论所涉及的语言的，该公司的管理听起来疯狂。对于除了一些小的应用程序之外的任何，怎么能说是经济合理重写了整个代码库，而不是仅仅雇用一个人有一些技巧在正确的语言？这与众所周知的问题企业：？！太多闲钱
一直在发展现有的代码多久？如果它刚刚起步，我能理解这一点。如果它看到一个释放和具有活跃用户，它会的从不的道理把它扔掉。如果您捐赠的C＃代码初创拥有合适技能，想多少头的开始，他们将有超过你。
在完成.NET项目转换成Java之前，所有谁是转换项目的一部分，这些Java开发人员已经学会了C＃。所以，那么你就不再需要将其转换为Java语言（你可以扔掉这是在转换产生的所有Java代码），因为现在你有一个开发团队，可以做Java和C＃。问题解决了。 ：d
如果有那些已经分离或任何的它采用了面向服务的架构的任何组件，则可以设想在一个时间（其中每个单独的部件是重写）迁移一个组件，并且仍然具有部件相互交谈使用相同的可互操作的网络协议。大概取决于我们在谈论什么类型的应用程序。
请确保您有吨的试验，因为在这里你最不希望它这样的迁移会咬你。
你有没有在生产更多.NET或更多的Java应用程序。如果您已经在净服务器和应用程序进行了大量投资，为什么不问在Java开发人员中的志愿者移动到.NET？语言和语法非常相似，所以最困难的部分是学习框架，除非他们将所有时间都花在做甚至学习框架UI开发并不难。
在我们的办公室，我们有一些非常好的开发商谁需要来回移动Java和.NET之间。
为了证明管理，你总是需要在投资回报率和数量方面谈。告诉他们，如果您将这些应用程序，这将需要时间大量，QA资源，并可以很容易地退居二线，如果它得到适当降低优先级的一些其他项目或新的发展采取的重要性。
我有成功的时候我给他们的时间表，投资回报率，工作涉及，资金介入等。
所以现在来点实际的，我认为Java开发人员将能够支持C＃，除非他们有针对微软technolgies一些基本的心理障碍。
看一看 Net2Java ，该puports协助从转换代码C＃与Java。我怀疑这将是完美的，但它的一个方法，从任务中删除了不少苦工，让你有不兼容的框架调用和语言功能的扭结来磨合。
一旦你这样做，你的任务是像任何其他大型迁移项目 - 测试，测试再测试。单元测试，系统集成测试，那么最终用户测试。你应该havew那些你与原来的应用程序所使用的测试已经到位，除了单元测试，他们将仍然是相关的。
如果决定这样做，你会从一个混合的方法，你基本上可以混合使用C＃和Java在同一应用程序，因为这将场景从一个瀑布转换更改为逐步迁移最有可能受益。在这里，我知道的两种可能性：
1）IKVM（ http://www.ikvm.net/ ），其允许用户运行在.NET运行时的Java代码。这允许Java代码调用C＃代码，反之亦然。然后你就可以冻结C＃代码开发，并同时保持功能应用修订后的功能慢慢添加到Java的部分。
2）的Mainsoft（ http://dev.mainsoft.com/Default.aspx ？tabid = 130 ），它允许您编译.NET的字节码转换为Java字节码。他们有一个免费的入门级产品。我的产品没有任何经验，但他们主要推广我们的平台，只有Java中可用。在
我不是 Java 专家，但根据我在作为 C# 爱好者的同时使用 Java 代码的经验，以下是一些可能令人头疼的问题：
- 泛型在 Java 和 C# 中的实现方式不同。
- Java 和 C# 之间的装箱/拆箱行为不同
- Java 类命名约定 + 大量 C# 生成代码
- 字符串处理（即Unicode/ASCII 问题）可能会出现问题，具体取决于所移植的 Java/C# 代码的质量。
就我个人而言，我认为从头开始写作根本不是一个坏主意。因为您已经有了一个工作架构。
我有点惊讶没有人甚至建议拒绝迁移的想法。
我不相信C＃开发人员可以强制切换到Java（反之亦然），因为他被告知（当然，如果他有枪，也许威胁则）。我要花很多时间，运动和激情，掌握至少一个技术堆栈。你不能用一个新的技术开始过夜，期望提供相同的质量。
我个人不打扰直到被告知开始迁移。在这一点我想告诉大家，我是.NET的家伙经理并不会切换到另一种技术，只是因为他们决定。
至于技术方面，它不是不同，而是库及其功能的语言语法。当然，如果所有最新的钟声和.NET 3.5口哨使用已被广泛那么语言差异将为您提供一个真正的挑战。
这当然是一个有趣的方式，就决定从.NET应用程序迁移到Java。有人做过不涉及麻烦的想法...
也许你可以使用 jni4net - 开源桥？ 或 我知道其他的选择。
