Community
Participate
Working Groups
Build ID: M20060921-0945 Unless this is possible some other way (I don't use much of Locales and ICU).. I need the opportunity to change settings on the NumberFormat objects created to be shared across converters. Specifically to switch off grouping (234,567,890). Currently I have to insert two lines into UpdateStrategy.java: private static Map getConverterMap() { // using string-based lookup avoids loading of too many classes if (converterMap == null) { //NumberFormat to be shared across converters for the formatting of integer values NumberFormat integerFormat = NumberFormat.getIntegerInstance(); ((DecimalFormat) integerFormat).setGroupingUsed(false); //NumberFormat to be shared across converters for formatting non integer values NumberFormat numberFormat = NumberFormat.getNumberInstance(); ((DecimalFormat) numberFormat).setGroupingUsed(false); converterMap = new HashMap(); converterMap .put( // etc. Any ideas for the best way to allow this (and maybe other) setting(s) to be changed? (Or an alternative solution outside of the data binding code)
My guess is that the ICU4J format customization is the same as the Java customization[1]. If the defaults don't work for you then you can extend UpdateStrategy and provide your own converters with the customized formats. We've exposed static initializers on NumberToStringConverter and StringToNumberConverter that accept a NumberFormat for this purpose. [1] http://java.sun.com/docs/books/tutorial/i18n/format/decimalFormat.html
(In reply to comment #1) > My guess is that the ICU4J format customization is the same as the Java > customization[1]. If the defaults don't work for you then you can extend > UpdateStrategy and provide your own converters with the customized formats. > We've exposed static initializers on NumberToStringConverter and > StringToNumberConverter that accept a NumberFormat for this purpose. > > [1] http://java.sun.com/docs/books/tutorial/i18n/format/decimalFormat.html > I'd rather not duplicate all of the converter map static stuff in the class and implement it in another virtually identical class. Can we move the two 'shared NumberFormat' local variables from 'private static Map getConverterMap()' to private static fields, which are initialized by getConverterMap() if they are null, on first use? Then expose public static methods like setIntegerFormat() and setDecimalFormat(). This would allow me to override the 'standard' number formatters used throughout DataBinding before I bind anything, and I can use data binding as-is without extending core classes.
(In reply to comment #2) > Can we move the two 'shared NumberFormat' local variables from 'private static > Map getConverterMap()' to private static fields, which are initialized by > getConverterMap() if they are null, on first use? > > Then expose public static methods like setIntegerFormat() and > setDecimalFormat(). My initial feeling is that this isn't a path we should take. One reason is that the current implementation has bug (bug 198466) in that it assumes the default Locale when the class is created. We need to be retrieving the Locale on each invocation to ensure that we function in environments where multiple users are running on the same VM (e.g. servlet container). We don't want this to be set statically because it would affect other consumers of UpdateStrategy in the same classloader. You could also have the problem that someone else could step on your setting of the static value. If we were to make something to customize the process my initial feeling is that it would need to be at the instance level rather than class level. You might want to take a look at NumberFormatFactory. It looks like you can create your own NumberFormat implementations per Locale and set it with NumberFormat.registerFactory(NumberFormatFactory factory). I haven't used it but it might satisfy your needs.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
