I would suggest instead just ditching double and Double altogether and using BigDecimal instead for ALL fields of FIX type "float", as very few monetary values (for example) can actually be represented in IEEE 754 format with 100% accuracy

Also, I'm currently working round issues with, for example, "Percentage" format fields which need to be multiplied by 100 to get from the factor value that FIX specifies to the percentage value needed by our system (e.g. from "0.0386" to 3.86%) as this may introduce rounding errors and/or make previously-ignorable inaccuracies significant: for example multiplying a BidYield of 0.0386 by 100.0 and converting the result to String results in 3.8600000000000003 (%)

I'm therefore having to extract field data using Message.getString(int) and then construct a BigDecimal from the String value. My life would be MUCH easier if DoubleField.getValue() just returned a BigDecimal! OK, for backwards compatibilty it might be necessary to add a DoubleField.getBigDecimal() method instead, plus appropriate implementations of DoubleField.setValue(BigDecimal) and valueEquals(BigDecimal)

There is an option for the code generator to use BigDecimal instead of double for fields like price and quantity. The generated code can be used as a replacement for the default QFJ message JARs. The enabled the feature pass a "-Dgenerator.decimal" option on the command line when running the generate.code Ant target.