Hi! We have discussed on IRC about making ICU4J [1] our default implementation of the java.text package. The ICU4J api contains few classes that are almost a one-to-one replacement of the java.text API, as well as some classes that are needed for correct operation. The library is copyright by IBM and is licensed under the X license, so I guess there will be no problem using it for Classpath, I would like to have other opinions here. I had the opportunity to read about this library and if I have understood well everything, even Sun JDK uses it for the main implementation of java.text, this will close the gap in functionality for this package, and makes us a little ahead if we want to integrate the two environment at some point (how I like to write this! Still I can't believe it happened!!) Not everything is easy as it seems, though; for example, the Collator stuff does not support full decomposition, and this will have to be implemented. I don't know the internals yet, so I cannot be sure of all the implications, but I guess that we could add some of our old implementation to the class to integrate it. With Mark, I've discussed about some possible ways to integrate this stuff. The one that seems to be most useful is to add the library as is into the /external directory of Classpath then write wrapper classes in the java.text package. This way we don't have to change code inside ICU4J, and we can also take our old implementation at hand. I'm open to suggestions, here. In the meantime, I'm working on the DecimalFormat class, as this is the one that takes less work (and I know it well, as I've spent the last two months on this :). Thanks, Mario [1] http://icu.sourceforge.net/ -- Lima Software, SO.PR.IND. s.r.l. http://www.limasoftware.net/ pgp key: http://subkeys.pgp.net/ Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/
Attachment:
signature.asc
Description: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente
