如何进行表达式求值，就如Javascript中的eval

问题终于被发现，可解决一起来。。。
  

public static void main(String[] args); {

    double d1 = 0.3, d2 = 55.8;
    double d = d1+d2;
    System.out.println(d);;
}

输出：56.099999999999994
这与56.1当然不等。经过JVM运算后精度发现了变化，我记得这种情况在Java specification中提到过。可是我求 60.3+55.8 却 ＝ 116.1，再加大分母，640.3+54.8 输出 ：695.0999999999999
我在JDK1.2以上都试验了，结果一样到底是什么原因 在C#中不存在这个现象。

高精度的数值计算比较使用java.math.BigDecimal

只能这样玩了：

        BigDecimal bd1 = new BigDecimal(d1);.setScale(3, BigDecimal.ROUND_HALF_UP);;
        BigDecimal bd2 = new BigDecimal(d2);.setScale(3, BigDecimal.ROUND_HALF_UP);;
        BigDecimal bd3 = bd1.add(bd2);;
        
        System.out.println(bd3);;

是的，单独处理可用BigDecimal，实际我的业务层表现对于货币型都是用BigDecimal来处理的。要对字符串表达式来进行比较运算，由于表达式可能是不同类型不同精度的表达式，要处理好看来只能自己再在JEP上写个了，JEP好象可以扩展。

BigDecimal
public BigDecimal(double val)Translates a double into a BigDecimal. The scale of the BigDecimal is the smallest value such that (10scale * val) is an integer.
Note: the results of this constructor can be somewhat unpredictable. One might assume that new BigDecimal(.1) is exactly equal to .1, but it is actually equal to .1000000000000000055511151231257827021181583404541015625. This is so because .1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the long value that is being passed in to the constructor is not exactly equal to .1, appearances notwithstanding.

The (String) constructor, on the other hand, is perfectly predictable: new BigDecimal(".1") is exactly equal to .1, as one would expect. Therefore, it is generally recommended that the (String) constructor be used in preference to this one.

觉得如果没有什么必要的话,不妨试一下这个,让SQL帮一下:
select 55555.04-25+25*(2.5+100.26)
即 select 表达式1 [, 表达式二 , ...]

嘻嘻,我不知道效率是怎么样的,只不过觉得是一种方法就提了出来.

是个办法。简单表达式可以，对数据库也没什么大的影响。问题我已解决，是在包了一层Format(###.##).