Archive for November, 2009

Critical change in Openbravo 2.50 public API

November 17, 2009
There has been a critical change in Openbravo 2.50 public API to be released in MP9 (November 30th, 2009). DAL implementation of columns referenced as Number in the Aplication Dictionary are mapped now to BigDecimal intead of Float. Getters and Setters for those columns are no longer using Float data type but BigDecimal. For example, instead of

java.lang.Float org.openbravo.model.common.currency.ConversionRate.getDivideRateBy()

now it is implemented as

java.math.BigDecimal org.openbravo.model.common.currency.ConversionRate.getDivideRateBy()

Main reason for this change is that original API (using Float) was wrong: arithmetic operations with Float properties might result in wrong results since java can not represent float-point precisely

As a result, modules and customizations using DAL getters or setters of columns with reference Number will need to be fixed before updating your instances to MP9. The fix is quite simple: just replace the Float method (in getters) or the Float parameter (in setters) by a BigDecimal one.

By November 15th 2009, from almost 100 published modules there are only three affected by this API change:

 

  • Invoice Register Book
  • POS Sync Webservice
  • IDL
  • 347 report
The four of them will be fixed by Openbravo team and a new versions including that fix will be published at the same time MP9 is published, so updates applied from Central Repository -using scan for updates in Openbravo Module Management window- will be transparently applied without errors. Openbravo team will continuously monitor new published modules during the next months to avoid an instance running MP9 or higher to use a module using old API. We will keep all of you updated on our findings.

You have to take care about your not published modules. It is very simple to check if your module is broken because of this change: update your development instance to current pi repository -or to MP9 after publishing- and build the system: the error will be clearly raised by your system.

Openbravo is strongly commited to keep its public API stable within major versions but there is no point to keep stable something if it is wrong. We have tried to minimize the pain by temporarily creating duplicated getters and setters using both data types (Float and BigDecimal) and setting the Float ones as deprecated to allow a gradual fix of the problem. But it is not possible to have two methods with identical signature and different return type and other approaches would have lead into a more painful solution of the problem.

I apologize for any inconvenience it might cause. This alert has been announced in Openbravo Developers forum:

http://forge.openbravo.com/plugins/espforum/view.php?group_id=100&forumid=549512&topicid=7005952

Please monitor that thread to keep updated on the issue.
Thanks,
Ismael