- on a release (created from Github), publish to
<https://github.com/unicode-org/icu/packages> as
1. icu4j-for-cldr
2. utilities-for-cldr
- also fix a doc bug in DecimalFormat
- this is intended for CLDR use.
- a tag such as 'cldr/2019-09-15' will turn into a
maven version '68.1-SNAPSHOT-cldr-2019-09-15'
* Throw UnsupportedOperationException for "unsanctioned units"
* Deal with the parent issue for LongNameMultiplexer
* Fix NullPointerException: UnitConversionHandler.processQuantity must
call fParent.processQuantity
* toSkeleton not supported for not-built-in units
* Add and use interface
LongNameMultiplexer.ParentlessMicroPropsGenerator
* Match up C++ and Java unit tests in NumberFormatterApiTest.java
* Permit user-override of precision() for usage(), closes icu-units#95
* Use BogusRounder to propagate mathContext.
* Port C++ change from PR #1322, commit c84ded050a, to Java.
* Test the usage-without-unit error. Document it in
NumberFormatterSettings.java
* General review and corrections.
This is the java port of ICU-21043 (for C++)
This PR fixes
ICU-21043 Erroneous date display in indian calendar of all dates prior to 0001-01-01.
ICU-21044 Hebrew Calendar calculation is incorrect when the year < 1
ICU-21045 Erroneous date display in islamic and islamic-rgsa calendars of all dates prior to 0622-07-18.
ICU-21046 Erroneous date display in islamic-umalqura calendar of all dates prior to -195366-07-23.
The problem in the IndianCalendarl is
ICU-21043 the gregorian/julain convesion is wrong. Swith to use the
calculation function in the Calendar class.
The problem in the HebrewCalendar is
ICU-21044 the use of bulit in / is wrong when the year or month could be < 1.
The problem in the IslamicCalendar is
ICU-21045: The math of % negative number for year and month is wrong.
Also add tests to exhaust test 8000 years for all calendar. In quick
mode, only test 2.5 years.
reduce the number of date in quick mode
Internal API VersionInfo.javaVersion() maps Java version number to 4 integer fields. Each field must be up to 255. However, recent OpenJDK 8 update exceed this range.
Luckily, we have only one reference in our code base for checking Java version. CharsetUTF16 uses maxBytePerChar = 4 for Java 5 and older, maxBytePerChar = 2 for newer Java version. Because we no longer support Java 5 runtime, we don't need this conditional check.
We don't have any other uses of VersionInfo.javaVersion(). Java's version range is not what we can control, so I decided to delete the internal use only API completely.
In the test data from rbbitst.txt, two or more adjacent boundary markers with
no intervening test data were accepted, with no indication of a problem.
This situation occurred, as described in bug ICU-21178, with a bad import of
some test cases from CLDR. PR #1194 corrected the problem with the test data
in ICU4C. This PR adds code to flag this situation in the test data, and
also propagates the data fix to ICU4J's copy of rbbitst.txt.
Change the mapping from rule number to boundary position to use a simple array
instead of a linear search lookup map.
Look-ahead rules have a preceding context, a boundary position, and following context.
In the implementation, when the preceding context matches, the potential boundary
position is saved. Then, if the following context proves to match, the saved boundary is
returned as an actual boundary.
Look-ahead rules are numbered, and the implementation maintains a map from
rule number to the tentative saved boundary position.
In an earlier improvement to the rule builder, the rule numbering was changed to be a
contiguous sequence, from the original sparse numbering. In anticipation of
changing the mapping from number to position to use a simple array.
For identifying text that needs to be handled by a word dictionary for Break Iteration,
change from using a bit in the character category to sorting all dictionary categories
together, and recording the boundary between the non-dictionary and dictionary ranges.
This is internal to the implementaion. It does not affect behavior.
It does increase the number of character categories that can be handled using a
compact 8 bit Trie, from 127 to 255.
- Check non-lenient rules before call lenint parsing
- Remove logKnownIssue 9503 from test code
- Adjust TestAllLocales test on ICU4C
- Add lenient checks on ICU4J
