summaryrefslogtreecommitdiffstats
path: root/text
Commit message (Collapse)AuthorAgeFilesLines
* Dead code/cruft removal in the collation code.Elliott Hughes2010-04-231-2/+3
| | | | | | | | | | | | | I've also renamed ScopedUtfChars::data to ScopedUtfChars::c_str, by analogy with std::string (since this method has always been more like c_str than data). This also fixes a few leaks on error paths. The old code used to go all the way into native code to return a constant hash code of 1, so I've removed all that and switched to the idiomatic bogo hash code (with the idiomatic comment). Change-Id: I25da8c422155860b5ab348786d369c6c7598135c
* java.text.RuleBasedCollator fixes.Elliott Hughes2010-04-221-5/+6
| | | | | | | | | | | | | | Add expectations for broken harmony tests, add our own equivalent (but correct) tets, and fix the bug turned up by the correct tests: the icu4jni RuleBasedCollator was using toString to convert a CharacterIterator to a String, resulting in iteration over the result of Object.toString (the class name and identity hash code) rather than the characters of interest. Also shut javac up about non-ASCII characters in Locale.java. Bug: 2608742 Bug: 2608750 Change-Id: I2171789058c8116eacd7e5815bd483f0bc07c69b
* Update to the latest upstream collator tests.Elliott Hughes2010-04-222-708/+284
| | | | | | | | | | I've pulled out the not-obviously-insane stuff we added, though I don't know how useful it is. This change is mainly about reverting our broken changes to these tests. Bug: 2608750 Bug: 2608742 Change-Id: Ia4d0a7b12bfc5dfc3fad4b72254918acf74b418d
* Merge LocaleData and Resources, rename Resources to ICU.Elliott Hughes2010-04-168-73/+35
| | | | | | | Also move our ICU tests into our little tree of tests. Bug: 2596471 Change-Id: I73b53d74c26ef9bf670f12cac58b51ba61eefead
* merging FRF15 for dalvik-devBrian Carlstrom2010-04-161-0/+1
| | | | Change-Id: Ic8c9dea280d38cba8e55f962f0d8df843aea8e35
* Change DecimalFormatSymbols to have a field per symbol.Elliott Hughes2010-04-161-71/+76
| | | | | | | I'd been wanting to do this for some time, but cleaning up the recent performance changes I made to Formatter was the final straw. Change-Id: I6d516de66a0bed5e759bca590b4cc124ce2eb712
* Remove "Messages" from the nio, prefs, sql, text, and x-net modules.Elliott Hughes2010-04-1412-508/+179
| | | | | | | | | | Also remove an file of unused messages from luni, and inline one of luni's other files. (There are plenty more.) Also remove some German translations of bouncycastle messages (that are actually in English anyway). Change-Id: I9c565f6f2201a5d877eba5bf0af4ffad7b769984
* Use the same documentation in all the methods that take a format string.Elliott Hughes2010-04-131-12/+11
| | | | Change-Id: I8e7d06df72a7b8db9edd17aa2748800329e837fa
* Improve documentation about the user's default locale.Elliott Hughes2010-04-139-96/+59
| | | | | | | | | | Add a bit of text to Locale's class documentation, and include a link from every method that uses Locale.getDefault(). Also try to consistently say "user's default locale", as a subliminal hint that this isn't necessarily the developer's locale, nor en_US. Bug: 2593000 Change-Id: Ieebe864ed6b9fecbfef5d5415269299739cedd1b
* Tidy up our getAvailableLocales methods to actually ask ICU4C.Elliott Hughes2010-04-0111-56/+16
| | | | | | | | | These specialized methods are little used, and in several cases ICU itself just returns the list of locales, but that's ICU's business, not ours. As long as ICU is in charge of our locale-specific data, it should be responsible for answering questions about what locale-specific data is available... Change-Id: Idc8a66bbf7fcbc6b06e30929e6a7af3fe30ab7d1
* Add Java 6's Calendar API changes.Elliott Hughes2010-03-312-2/+2
| | | | | | | | Also correct two javadoc mistakes I added, and bring back the latest harmony java6 CalendarTest. Bug: 2497395 Change-Id: If481390948ca93d5f709a8ed4585991889de9f8b
* Add Java 6's exponent separator to DecimalFormatSymbols.Elliott Hughes2010-03-292-75/+147
| | | | | Bug: 2497395 Change-Id: Ic552fa828649bae882e508a62a44073d1038b5c0
* Fix all our java.text.Bidi failures.Elliott Hughes2010-03-262-19/+32
| | | | | | | | | | Two are invalid tests where we behave the same as the RI. The third reflects a difference between ICU4C and the RI, so I've added code to recognize that case and paper over the crack. I've also tidied up a bit more. With any luck, I'll never see these files again... Change-Id: I278502fbdea039e9a2318df830dc0b55851e96c0
* Java 6 changed CollationKey from final to abstract.Elliott Hughes2010-03-263-98/+28
| | | | | | | | | | | | | | I've also taken the opportunity to tidy up our implementation a little, though my hands are tied by (a) the fact that our concrete classes are in a separate package from our abstract classes and (b) frameworks/base actually pokes about with our icu4jni collation code (http://b/2417080). I've also tidied up a bunch of dead code. In particular, it's silly for us to check parameters in Java that will be checked in native code (and that one would assume will be valid most of the time anyway). Bug: 1635883 Change-Id: I7db3c1ff1f0d23cb85604f9c8eb995e4488d7c0a
* Clean up a few toStrings.Elliott Hughes2010-03-252-2/+4
| | | | | | | I couldn't find any more that were using getClass() rather than getClass().getName(). Change-Id: I30b375748d36bc36d1e6999349fc472496456746
* Add Java 6's getAvailableLocales/getInstance to DateFormatSymbols and ↵Elliott Hughes2010-03-249-94/+256
| | | | | | | | | | | | | | | | | | | | | | | | | | | DecimalFormatSymbols. This patch also improves the documentation of all getAvailableLocales methods to clarify exactly what "available" means. Note that at the moment, many of our implementations just return Locale.getAvailableLocales. It turns out that ICU does the same in most cases, but I'll come back in a separate patch and add code so we just pass these down to ICU, and wash our hands of the matter. I've rewritten DateFormatSymbols.equals, which was very wrong. The time zone names comparison had an invalid optimization, and its slow-path loop was wrong too: it only ever tested values against themselves, which isn't likely to have been the author's intention. I've added toString overrides to DateFormatSymbols and DecimalFormatSymbols, because I need them every time I work on these classes. I've made the constants in DecimalFormatSymbols static final, and given them idiomatic names. (I still think we might benefit from breaking these into separate fields, as in the serialized form, but that's a separate issue.) Finally, and unrelatedly, I've added a comment to BreakIteratorProvider that I missed in my last change to that file. Change-Id: I5d6cb30f9afdb502d38353d8a624dc2f0fef41ac
* Add the Java 6 java.text.spi and java.util.spi interfaces.Elliott Hughes2010-03-227-1/+415
| | | | | | | | | | | | We don't currently use these, and don't necessarily plan to. Full support would have a run-time cost, and it's not obvious that it would be particularly useful. Code search can't actually find any users of this stuff in the wild outside of the various VM implementations and their test suites. Bug: 2497395 Change-Id: Ie25aef73ece6d1fd169fdcb7b2f847761d77914d
* Remove all remaining "@since Android" tags.Elliott Hughes2010-03-221-4/+3
| | | | | | | I've fixed a few typos, and removed a few of the more egregiously nonsensical or incorrect comments that were nearby. Change-Id: I35851baebd532f949cc269f4738a26eeb9b6e697
* Track Java 6's BreakIterator API changes.Elliott Hughes2010-03-192-339/+0
| | | | | Bug: 2497395 Change-Id: Iaef75bbd946bebe6201b5f52564bcaf8a4d0e56e
* Clean up the Java side of the ICU interface a bit.Elliott Hughes2010-03-192-45/+22
| | | | | | | | My original intention was just to add the missing "final" on a few classes, but our BreakIterator implementation struck me as excessively bloated and confusing. Change-Id: I2d2dccafe8ec91124f3c83909c9ec647cc2d51e2
* Add's Java 6's DecimalFormat.setRoundingMode (et cetera).Elliott Hughes2010-03-184-124/+394
| | | | | | | | | | | | | | | | | | Format and NumberFormat's bogusly-public constructors became protected with Java 6. DecimalFormat gained more control over rounding behavior. There's a slight mismatch with our ICU4C-based implementation in that ICU4C doesn't support RoundingMode.UNNECESSARY, so I've had to fake that (but I doubt it's used much, if at all). I've pulled out the obviously Android-specific tests from the harmony DecimalFormatTest.java, but I've only brought back the rounding mode changes from the current harmony code to avoid the new tests' dependencies. I've also added one new test of my own, to check that setMaximumFractionDigits affects rounding as it should (since the harmony tests don't test this, and it's somewhat subtle). Bug: 2497395 Change-Id: Ifafc8bb051e078ead988073281f5c33f0aeb130a
* Add Java 6's Scanner.reset and fix RuleBasedCollator's javadoc.Elliott Hughes2010-03-181-21/+19
| | | | | | | | (The harmony ScannerTest.java is quite different from ours, and doesn't test this trivial method anyway.) Bug: 2497395 Change-Id: I8b2b3db7233f766ef70bfdbfdcdfbd0f23e4bdb4
* Fix all instances of "new Integer" (et cetera).Elliott Hughes2010-03-112-17/+9
| | | | | | (This doesn't include libcore/xml/ because I don't want to get in the way there.) Change-Id: I46f638105d26e82d09128fca605117322229e146
* am c9b3aeb6: Prevent java.text.Normalizer from getting a default constructor.Elliott Hughes2010-03-041-0/+2
|\ | | | | | | | | | | | | Merge commit 'c9b3aeb659ac420bdc3d3c550423ab1fec5fde4c' into dalvik-dev * commit 'c9b3aeb659ac420bdc3d3c550423ab1fec5fde4c': Prevent java.text.Normalizer from getting a default constructor.
| * Prevent java.text.Normalizer from getting a default constructor.Elliott Hughes2010-03-031-0/+2
| | | | | | | | The dalvik continuous build's new jdiff run caught this.
* | am 10ebc7d0: Merge "Implement (but @hide) java.text.Normalizer from Java 6."Elliott Hughes2010-03-013-0/+265
|\ \ | |/ | | | | | | | | | | Merge commit '10ebc7d0b84dcb98e1a7eeac96ef06acdfc8d184' into dalvik-dev * commit '10ebc7d0b84dcb98e1a7eeac96ef06acdfc8d184': Implement (but @hide) java.text.Normalizer from Java 6.
| * Implement (but @hide) java.text.Normalizer from Java 6.Elliott Hughes2010-03-013-0/+265
| | | | | | | | | | | | | | | | Based on https://android-git.corp.google.com/g/42516. Includes the harmony tests from their Java 6 branch. Bug: 719001
* | Resync a load of tests with upstream, make our build faster.Elliott Hughes2010-02-192-13/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I started off with a mission to remove uses of dalvik.annotation.* (stuff like @TestTargetNew and other useless junk that just makes it harder to stay in sync with upstream). I wrote a script to go through tests showing me the diff between what we have and what upstream has, thinking that in cases where upstream has also added tests, I may as well pull them in at the same time... ...but I didn't realize how close we were to having dx fill its 1.5GiB heap. After trying various alternatives, I decided to bite the bullet and break core-tests up into one .jar per module. This adds parallelism back into this, the slowest part of our build. (I can do even better, but I'll do that in a separate patch, preferably after we've merged recent changes from master.) Only a couple of dependencies were problematic: the worthless TestSuiteFactory which already contained a comment suggesting we get rid of it, and the fact that some tests -- most notably the concurrent ones -- also contained main methods that started the JUnit tty-based TestRunner. (In the long run, we want to be running the harmony tests directly from a pristine "svn co" of upstream, using DalvikRunner. But this will be a big help in the meantime, and starts the work of getting our current copy of the tests into a state where we can start to extract any meaningful changes/additions we've made.)
* | Fix a few of our FindBugs "high" warnings.Elliott Hughes2010-02-122-34/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RuleBasedBreakIterator was breaking the equals/hashCode contract. Various classes were calling toString on arrays, which isn't very useful. GregorianCalendar was missing a null/instanceof check. (FindBugs complained about the former, but the super.equals would actually take care of that. The lack of the explicit "instanceof" did mean that we could throw ClassCastException if you had a Calendar that wasn't a GregorianCalendar, though. [Not easily testable, and I hope we'll replace our calendars with ICU4J's before we actually have another Calendar subclass.]) Collator's cache was broken, but luckily never had anything inserted into it anyway.
* | Remove obviously bogus @KnownFailure annotations.Elliott Hughes2010-02-037-24/+0
|/ | | | | | | | | | | | | | We've already agreed @KnownFailure Must Die (to be replaced by expectations for DalvikRunner), but some are -- I think -- obviously in need of investigation. This patch removes @KnownFailure for all cases where the reason looks bogus. I've left the @KnownFailure annotations in cases where I it looks "reasonable" in that we simply haven't implemented the functionality (pack200, say), and a few other cases. Those should probably be done in a separate patch that adds expectations at the same time. But these ones, I think, all need investigating. (There's a scary number of Arabic-related bugs in here, given that we're supposed to be shipping Arabic in froyo.)
* FindBugs didn't like setInternalField, and neither do I.Elliott Hughes2010-02-013-116/+26
| | | | | | | | | | | | | | | | "Exception is caught when Exception is not thrown in java.text.DecimalFormat$1.run()" Since it will always fail anyway, because those fields don't exist, let's just junk it. It turns out that getInternalField is similarly useless, so junk it too. I've tidied the whole readObject method so it's somewhat readable now. I also fixed this FindBugs warning in passing: "Method java.text.DecimalFormat.parse(String, ParsePosition) invokes inefficient new Long(long) constructor; use Long.valueOf(long) instead"
* Fix "unmappable character for ascii" warnings in libcore tests.Elliott Hughes2010-02-011-5/+7
| | | | The libcore "core" and "core-test" builds are now warning-free. (For Java.)
* Change NumberFormatTest to match ICU's behavior.Elliott Hughes2010-01-291-16/+14
| | | | | | | | | ICU uses a non-breaking space after the euro sign in its currency formats, where the RI uses ASCII space. ICU's behavior seems more reasonable (to the extent that any kind of space after a currency symbol is reasonable). Also uncomment the Arabic tests --- I fixed right-to-left number formats a few weeks ago.
* Fix tests.api.java.io.SerializationStressTest3.test_18_116_writeObject.Elliott Hughes2010-01-291-1/+1
| | | | | | | The dead field 'minExponentDigits' was of type 'byte', not 'int'. Also add detail to serialization exception messages (this isn't just test code --- ObjectInputStream calls this).
* Use DecimalFormatSymbols' new default constructor for speed.Elliott Hughes2010-01-282-15/+8
| | | | | | | | This brings "new DecimalFormat" down to ~80us (from ~260us before this patch, or ~600us this time last week). Also remove some dead code and tighten up some accessibility. Depends on https://android-git.corp.google.com/g/38877.
* am ff3a96c9: am c4f93305: Fix for ↵Brett Chabot2010-01-271-6/+0
|\ | | | | | | | | | | | | | | | | DecimalFormatTest#test_formatToCharacterIteratorLjava_lang_Object Merge commit 'ff3a96c9055888140893158fff8b33831b949e49' * commit 'ff3a96c9055888140893158fff8b33831b949e49': Fix for DecimalFormatTest#test_formatToCharacterIteratorLjava_lang_Object
| * Fix for DecimalFormatTest#test_formatToCharacterIteratorLjava_lang_ObjectBrett Chabot2010-01-211-6/+0
| | | | | | | | | | | | | | | | Add additional logic to skip checks that require specific locales. Bug 2386416 Change-Id: Icc30e04d393a22b272966555e617598323aefa0b
* | Fix NumberFormat's behavior with BigInteger and custom Number subclasses.Elliott Hughes2010-01-276-97/+28
| | | | | | | | | | | | | | Also remove a few bits of cruft I ran across, and stop duplicating the documentation between NumberFormat and DecimalFormat. Bug: 2387934
* | Rename icu4jni's DecimalFormat to NativeDecimalFormat, to reduce confusion.Elliott Hughes2010-01-271-7/+6
| |
* | Simplify our DecimalFormat.Elliott Hughes2010-01-263-136/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both the is-a and has-a hierarchies for our DecimalFormat implementation were over-complicated. This patch starts to address that, and makes cloning twice as fast (50us versus 100us), but not as fast as I'd like (<10us), and without making much of a dent in the time it takes to create a new NumberFormat (550us versus 600us). The speed of cloning is important because Formatter has a hack that uses it, and I want to change NumberFormat so that it always hands out clones... at least until I have time to make "new NumberFormat" acceptably fast. Also fixes DecimalFormat.applyLocalizedPattern (which used to behave as if you'd called applyPattern).
* | Fix Date.toString.Elliott Hughes2010-01-142-51/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Date.toString was using the TimeZone id ("America/Los_Angeles") rather than the time zone short name ("PDT" or "PST", depending on time of year). The naive fix made things 5x slower, so I improved Resources.getDisplayTimeZone so the fixed Date.toString is only 2x slower. This could be improved further with a faster getDisplayTimeZone. I hoped to replace the body of Date.toString with a call to SimpleDateFormat, but that turns out to be 40x slower. This patch also optimizes SimpleDateFormat to bring the gap down to 8x by using Resources.getDisplayTimeZone instead of asking for all the strings. (Note that these improvements refer to the hopefully common case of localized strings for the default locale. If you have the misfortune to need strings for other locales, the new code will be more like 600x faster. At 0.5s a call on the fastest current hardware, I hope no-one's actually doing that. Dalvik Explorer -- available on the Market -- needs to do it when generating summary reports, and it is indeed ridiculously slow. It uses two SimpleDateFormat objects per locale, so it takes 1s per locale, for about 60 locales. I've tested Dalvik Explorer with this patch, and it does fix that pathological behavior.) Also fix a bug I introduced in https://android-git.corp.google.com/g/36242 that meant that our zone names String[][] contained incorrect values (accidentally concatenating each successive value in a row), found by existing tests now we use more of those values. Also replace a couple of "new Integer" calls with Integer.valueOf for a modest speedup. Also factor out some duplication. Bug: http://code.google.com/p/android/issues/detail?id=6013
* | am eb9ea32d: am 53a6c01c: Fix ↵Brett Chabot2010-01-111-0/+5
|\ \ | |/ | | | | | | | | | | | | | | DecimalFormatTest#test_serializationHarmonyRICompatible. Merge commit 'eb9ea32d1468cf753dc0091dd7e639b6bd0cbd0b' * commit 'eb9ea32d1468cf753dc0091dd7e639b6bd0cbd0b': Fix DecimalFormatTest#test_serializationHarmonyRICompatible.
| * Fix DecimalFormatTest#test_serializationHarmonyRICompatible.Brett Chabot2010-01-081-1/+5
| | | | | | | | | | | | | | | | Skip the test if required Locale is not present. Bug 2343677 Change-Id: I0f2672bd4b56cc1685e7368921aaa1e9d4492cf0
* | Last bunch of NumberFormat speedups.Elliott Hughes2010-01-052-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't mess around with setCurrency in DecimalFormat.copySymbols when we're going to override any effect that call will have had in the next few lines: we always call setCurrencySymbol and setInternationalCurrencySymbol, so setCurrency is just wasting time. Replaces the NativeDecimalFormat.UNumberFormatSymbol enum -- which was only used for getting ints to pass to native code, using Enum.ordinal -- with ints. Adds a constructor to the java.text DecimalFormat so we can avoid cloning the DecimalFormatSymbols object we create for its private use. This is another 10% shaved off. I've also removed an unused local from the icu4jni DecimalFormat, so I can remove a then-unused getLocale method from the ICU DecimalFormatSymbols. I've rewritten the icu4jni DecimalFormatSymbols.clone to remove the scary constructor that took an arbitrary int and treated it as a uintptr_t when talking to native code.
* | Speed up DecimalFormatSymbols.Elliott Hughes2010-01-041-48/+10
| | | | | | | | | | | | | | | | | | | | We don't need to create temporary String objects; we can just pass a char directly. We also don't need to initialize aspects of our native peer if we know we're going to overwrite them straight away, and making copying into ICU the responsibility of the icu4jni class rather than the java.text is slightly cleaner. Together, these changes make creating a new NumberFormat about 20% faster.
* | Fix build (accidental API leak).Elliott Hughes2010-01-042-36/+4
| | | | | | | | | | Move a couple of methods into LocaleData -- where they should have been from the beginning -- so they're automatically hidden from our users.
* | Stop using ResourceBundle for locale data.Elliott Hughes2010-01-047-76/+75
| | | | | | | | This offers an additional speed increase and gets rid of a lot of native code.
* | am d3b06457: am 6cdbef55: Merge change I1d9b205f into eclairBrett Chabot2009-12-224-61/+128
|\ \ | |/ | | | | | | | | | | Merge commit 'd3b0645772fd3364575b93c74428ae19f88c4238' * commit 'd3b0645772fd3364575b93c74428ae19f88c4238': Skip locale dependent libcore tests if required locales are not present.
| * Skip locale dependent libcore tests if required locales are not present.Brett Chabot2009-12-224-73/+128
| | | | | | | | | | | | | | | | | | Previously these tests were marked as KnownFailures - which is undesirable since they can pass if the right Locale's are present on target. Bug 2335906 Change-Id: I1d9b205f740b71880c57b48f069c302c5cec8792
* | More ICU cleanup.Elliott Hughes2009-12-212-3/+2
| | | | | | | | | | | | | | | | | | | | Don't duplicate SimpleDateFormat.patternChars in native code when we can just access it directly. Also remove a bit more duplication in the native code, and remove the early scope closure in getCurrencyCodeNative. If we're going to waste space in that function, let's waste it on an explanation of why a seemingly useless assignment is actually totally necessary.
generated by cgit v1.1 at 2025-03-22 02:29:31 +0000