BigDecimal notation eclipse plugin or nice external tool

落花浮王杯 提交于 2019-12-06 20:02:23

问题


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.


回答1:


"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):

 // BigDecimal a = b - c * d;
 BigDecimal a = b.subtract( c.multiply( d ) );

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.




回答2:


I agree, it's very cumbersome! I use proper documentation (comments before each equation) as the best "solution" to this.

// a = b - c * d;
BigDecimal a = b.subtract( c.multiply( d ) )



回答3:


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.



来源:https://stackoverflow.com/questions/8636228/bigdecimal-notation-eclipse-plugin-or-nice-external-tool

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!