Java 经验与「；语言转换器；？

我读过几篇文章提到从一种语言到另一种语言的转换

我对这种工具的使用持怀疑态度。有人知道或有过关于VisualBasic到Java或vs转换器的经验吗？只举一个例子

，声称在这方面处于“世界领先地位”，但如果阅读以下内容：

提交人在信中说：

“MySQL用户的共识是，MS Access的自动转换工具不起作用。例如，将现有Access应用程序转换为Java的工具通常会产生80%的完整解决方案，而完成最后20%的工作比从头开始需要更长的时间。”

我们知道我们需要80%的时间来实现前80%的功能，另外80%的时间用于其他20%

那么有没有人尝试过这样的工具并发现它们是值得的呢？

尝试过了吗？不，实际构建的（多个）语言转换器

这里有一个我（和我的同事）为任务而构建的，用于将任务软件（用遗留语言JOVIAL编码）转换为可维护的C代码，并实现100%的自动转换。其中一个要求是不允许我们看到实际的源代码。别开玩笑了

你是对的：如果你的转化率只有中高（例如70-80%），那么完成转化的努力仍然非常重要，如果你真的能做到的话。我们的目标是95%以上，当被告知要像B2那样更加努力时，我们会做得更好。人们接受中高转换率的唯一原因是因为他们找不到（或不会提供资金！）更好的转换方式，坚持从现在开始，并接受这样一个事实，即以这种方式转换可能会很痛苦（通常他们不知道有多痛苦），但事实上比从头开始重建痛苦更小。（我恰好同意这一评估：一般来说，尝试从头开始重新编写大型系统代码的项目通常会失败，而使用中高转换率工具的转换的失败率并不高。）

现在有很多糟糕的转换工具，一些东西与大量的PERL代码一起在文本字符串上执行正则表达式，或者一些基于YACC的解析器，其代码生成基本上是编译单元中每个语句的一对一。前者是由那些从天上掉下来的人建造的。后者通常是由善意的工程师构建的，他们没有像样的编译器背景

对于一个非常糟糕的例子，请参阅我对这个关于COBOL迁移的问题的回答：，这正是一个直接语句转换器。。。产生了“JOBOL”这个词

要获得如此高的转换率，您需要高质量的解析器，并且需要构建高质量的翻译规则来保留语义，并针对目标语言属性和特殊情况进行优化。本质上，您需要可配置的编译器技术。IMHO，我们成功的原因是我们的团队，这是为了完成这项工作而设计的。（我是建筑师；请查看我的SO图标/简历）

很多仔细的测试也有帮助

DMS“知道”编译器对代码的了解，因为它有一个类似于编译器的感兴趣语言前端，并且能够构建AST、符号表、控制和数据流、调用图。它使用了编译器社区在过去半个世纪里发明的许多编译器技术，因为这些东西已经被证明在翻译中是有用的

DMS比大多数编译器知道的要多，因为它可以一次读取/分析/转换整个应用程序；大多数编译器坚持使用单个编译单元。因此，可以编写依赖于整个应用程序的翻译规则，而不仅仅是当前语句。我们经常添加特定于问题或应用程序的知识来改进翻译。这通常出现在转换语言的特殊功能或调用库时，其中必须将库调用识别为特殊的习惯用法，并将其转换为对目标库和语言构造的组合的调用

此功能用于构建翻译器（例如，JOVIAL翻译器）或特定于域的代码生成器

---

更常见的情况是，我们构建复杂的自动化软件工程工具来解决特定于客户的问题，例如程序分析工具（死代码、重复代码、样式错误代码、度量、架构提取等）和大规模更改工具（平台[非langauge]迁移、数据层插入、API替换等）

我使用了一个从C#到Visual Basic.NET的自动转换器。除了添加一些不必要的

If-True

语句之外，它工作得非常好

---

我也曾尝试使用Python将Python转换为C++，但由于缺乏对新型划分的支持，它无法正常工作。

我使用了一些工具将VB6项目转换为VB.Net，您可能希望这可能是这类事情的简单示例之一。我的经验是，所有的东西都必须仔细检查，有一半的东西不见了/错了

当然，我推荐手工移植，或者根据你所说的语言，如果你有机会对你的代码库做重大改进，我会考虑一个完整的改写。

---

马丁

我只试过免费和基本的付费转换器。但主要的问题是，很难对转换完全成功抱有信心

---

通常，它们最好用于一次手动转换代码部分，在这里您可以查看每段代码。根据我的经验，重写而不是转换通常是一个更好的选择。

影响跨语言转换成败的两个问题是语言的相对语义丰富性及其语义模型

• C语言的翻译+