Плагин eclipse с надписью BigDecimal или хороший внешний инструмент

Мне нужно сделать много операций с помощью BigDecimal, и мне посчастливилось выразить

Double a = b - c * d; //natural way

а

BigDecimal a = b.subtract(c.multiply(d))//BigDecimal way

является не только уродливым, но и источником ошибок и коммуникационных проблем между мной и бизнес-аналитиками. Они отлично умели читать код с помощью Doubles, но теперь они не могут.

Конечно, идеальным решением будет поддержка java для перегрузки операторов, но поскольку этого не произойдет, я ищу плагин eclipse или даже внешний инструмент, который делает автоматическое преобразование с "естественного пути" на "большой" путь".

Я не пытаюсь препроцитировать исходный код или динамический перевод или любую сложную вещь, я просто хочу, чтобы я мог вводить текст и получать текст, и сохранять "естественный путь" в качестве комментария в исходном коде.

P.S.: Я нашел этот невероятный смарт-хак, но я не хочу начинать манипуляции с байт-кодом. Возможно, я могу использовать это для создания транслятора Natural2BigDecimal, но я не хочу изобретать велосипед, если кто-то уже сделал такой инструмент.

Я не хочу переключаться на Scala/Groovy/JavaScript, и я также не могу, правила компании запрещают что-либо, кроме java, на стороне сервера.

Ответ 1

"Я не пытаюсь обработать исходный код... Я просто хочу, чтобы я мог ввести текст [bigDecimal aithmetic expression]".

Половина решения проблемы - это распознавание проблемы для того, что это такое. Вы точно хотите что-то препроцессить свои выражения BigDecimal для создания законной Java.

У вас есть только два основных варианта:

Отдельный "специфический для домена язык" и компилятор DSL, который принимает "стандартные" выражения и преобразует их непосредственно в Java-код. (Это один из препроцессоров). Это оставляет вам проблему сохранения всех фрагментов выражения вокруг и как-то зная, куда их помещать в код Java.
Инструмент, который читает исходный текст Java, находит такие выражения и преобразует их в BigDecimal в тексте. Я бы предложил что-то, что позволит вам закодировать выражения вне фактического кода и вставить перевод.

Возможно (украден из другого ответа):

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

со значением "скомпилируйте большое десятичное выражение в комментарии в его эквивалент java и замените следующий оператор этим переводом.

Чтобы реализовать вторую идею, вам нужна система преобразования , которая может применять правила перезаписи источника к источнику для преобразования (генерировать как специальный случай преобразования) кода. Это всего лишь препроцессор, который организован для ваших нужд.

Наш DMS Software Reengineering Toolkit с его Java Front End может это сделать. Для выполнения этой части преобразования нужен полный парсер Java. вам понадобится разрешение имени и типа, чтобы вы могли анализировать/проверять предложенное выражение для удобства.

Хотя я согласен с тем, что нотация Java as-is уродлива, и ваше предложение сделает ее красивее, мое личное мнение заключается в том, что это не стоит усилий. Вы в конечном итоге зависите от сложного инструмента (да, DMS сложна: манипулирование кодом непросто) для довольно незначительного выигрыша.

Если вы и ваша команда написали тысячи этих формул, или писатели таких формул были наивными для Java, это может иметь смысл. В таком случае, Я бы пошел дальше и просто настаиваю, чтобы вы записывали стандартный формат выражения, в котором он вам нужен. Вы можете настроить внешний интерфейс Java, чтобы определить, когда типы операндов имеют десятичный тип, и выполните переписывание для вас. Затем вы просто запускаете этот препроцессор перед каждым шагом компиляции Java.

Ответ 2

Я согласен, это очень громоздко! Я использую правильную документацию (комментарии перед каждым уравнением) как лучшее "решение" этого.

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

Ответ 3

Вы можете пройти маршрут оценки выражения. Существует достойный (хотя и платный) код на http://www.singularsys.com/jep. У Antlr есть рудиментарная грамматика, которая также выполняет оценку выражения (я не уверен, как это будет выполняться) в http://www.antlr.org/wiki/display/ANTLR3/Expression+evaluator.

Ни один из них не предоставит вам безопасность во время компиляции, которую вы имели бы с истинными операторами. Вы могли бы также написать различные классы на основе алгоритмов в чем-то вроде Scala, который поддерживает перегрузку оператора из коробки и будет беспрепятственно взаимодействовать с вашими другими классами Java.