BigDecimal notation eclipse 插件或不错的外部工具
我需要使用 BigDecimal 进行大量操作，并且我发现必须表达
Double a = b - c * d; //natural way
为
BigDecimal a = b.subtract(c.multiply(d))//BigDecimal way
不仅丑陋，而且是我和业务分析师之间出现错误和沟通问题的根源。他们完全能够用 Doubles 读取代码，但现在却不能了。
当然，一个完美的解决方案是java对运算符重载的支持，但由于这不会发生，我正在寻找一个eclipse插件，甚至是一个外部工具，可以自动从“自然方式”转换为“bigdecimal方式”。
我不尝试预处理源代码或动态翻译或任何复杂的东西，我只是想要一些可以输入文本和获取文本的东西，并在源代码中保留“自然方式”作为注释。
PS：我发现了这个令人难以置信的智能黑客，但我不想开始进行字节码操作。也许我可以用它来创建一个 Natural2BigDecimal 翻译器，但如果有人已经做了这样的工具，我不想重新发明轮子。
我不想切换到 Scala/Groovy/JavaScript，而且我也不能，公司规则禁止在服务器端代码中使用除 java 之外的任何内容。
I need to make a lot of operations using BigDecimal, and I found having to express
Double a = b - c * d; //natural way
as
BigDecimal a = b.subtract(c.multiply(d))//BigDecimal way
is not only ugly, but a source of mistakes and communication problems between me and business analysts. They were perfectly able to read code with Doubles, but now they can't.
Of course a perfect solution will be java support for operator overloading, but since this not going to happen, I'm looking for an eclipse plugin or even an external tool that make an automatic conversion from "natural way" to "bigdecimal way".
I'm not trying to preprocess source code or dynamic translation or any complex thing, I just want something I can input text and get text, and keep the "natural way" as a comment in source code.
P.S.: I've found this incredible smart hack but I don't want to start doing bytecode manipulation. Maybe I can use that to create a Natural2BigDecimal translator, but I don't want to reinvent the wheel if someone has already done such a tool.
I don't want to switch to Scala/Groovy/JavaScript and I also can't, company rules forbid anything but java in server side code.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
“我不是在尝试预处理源代码......我只是想要一些可以输入[bigDecimal算术表达式]文本的东西”。
解决问题的一半是认识到问题的本质。您确切想要一些东西来预处理您的BigDecimal表达式以生成合法的Java。
您只有两个基本选择：
独立的“领域特定语言”和 DSL 编译器，它接受“标准”表达式并将其直接转换为 Java 代码。 （这是一种预处理器）。这给您带来了保留所有表达式片段并以某种方式知道将它们放在 Java 代码中的位置的问题。
读取 Java 源文本、查找此类表达式并将其转换为文本中的 BigDecimal 的工具。我建议您在实际代码之外编写表达式并插入翻译。
也许（从另一个答案中窃取）：
其含义是“将注释中的大十进制表达式编译为其java等效项，并将以下语句替换为该翻译。
要实现第二个想法，您需要一个 程序转换系统，可以将源到源重写规则应用于转换（生成为转换的特例）代码。这只是一个可根据您的需求进行定制的预处理器
。 /a> 及其 Java 前端 可以这样做你需要一个完整的 Java 解析器来完成该转换部分；你需要名称和类型解析，以便你可以解析/检查建议的表达式是否合理
。你的建议会让它更漂亮，我个人认为这不值得付出努力。您最终会依赖于一个复杂的工具（是的，DMS 很复杂：操作代码并不容易），以获得相当小的收益。
如果您和您的团队编写了数千个这样的公式，或者这些公式的编写者不懂 Java，那么这可能是有意义的。在那种情况下，
我会更进一步，只是坚持您在需要的地方编写标准表达式格式。您可以自定义 Java 前端来检测操作数类型何时为十进制类型，并为您进行重写。然后，您只需在每个 Java 编译步骤之前运行此预处理器即可。
"I'm not trying to preprocess source code ... I just want something I can input [bigDecimal arithmetic expression] text".
Half of solving a problem is recognizing the problem for what it is. You exactly want something to preprocess your BigDecimal expressions to produce legal Java.
You have only two basic choices:
A stand-alone "domain specific language" and DSL compiler that accepts "standard" expressions and converts them directly to Java code. (This is one kind of preprocessor). This leaves you with the problem of keeping all the expression fragments around, and somehow knowing where to put them in the Java code.
A tool that reads the Java source text, finds such expressions, and converts them to BigDecimal in the text. I'd suggest something that let you code the expressions outside the actual code and inserted the translation.
Perhaps (stolen from another answer):
with the meaning "compile the big decimal expression in the comment into its java equivalent, and replace the following statement with that translation.
To implement the second idea, you need a program transformation system, which can apply source-to-source rewriting rules to transforms (generate as a special case of transform) the code. This is just a preprocessor that is organized to be customizable to your needs.
Our DMS Software Reengineering Toolkit with its Java Front End could do this. You need a full Java parser to do that transformation part; you'll want name and type resolution so that you can parse/check the proposed expression for sanity.
While I agree that the as-is Java notation is ugly, and your proposal would make it prettier, my personal opinion is this isn't worth the effort. You end up with a dependency on a complex tool (yes, DMS is complex: manipulating code isn't easy) for a rather marginal gain.
If you and your team wrote thousands of these formulas, or the writers of such formulas were Java-naive it might make sense. In that case,
I'd go further, and simply insist you write the standard expression format where you need it. You could customize the Java Front End to detect when the operand types were of decimal type, and do the rewriting for you. Then you simply run this preprocessor before every Java compilation step.
我同意，这太麻烦了！我使用适当的文档（每个方程之前的注释）作为对此的最佳“解决方案”。
I agree, it's very cumbersome! I use proper documentation (comments before each equation) as the best "solution" to this.
您可能会走表达式求值器的路线。 http://www.singularsys.com/jep 上有一个不错的（尽管是付费的）。 Antlr 有一个基本语法，也可以在 http://www.antlr.org/wiki/display/ANTLR3/Expression+evaluator。
两者都不会为您提供真正的运算符所具有的编译时安全性。您还可以使用 Scala 等语言编写各种基于算法的类，Scala 确实支持开箱即用的运算符重载，并且可以与其他 Java 类无缝地进行互操作。
You might go the route of an expression evaluator. There is a decent (albeit paid) one at http://www.singularsys.com/jep. Antlr has a rudimentary grammar that also does expression evaluation (tho I am not sure how it would perform) at http://www.antlr.org/wiki/display/ANTLR3/Expression+evaluator.
Neither would give you the compile-time safety you would have with true operators. You could also write the various algorithm-based classes in something like Scala, which does support operator overloading out of the box and would interoperate seamlessly with your other Java classes.