apply the configured number-length limit on the parse path

[pjfanning]

Follow-on to #94. XmlOptions.setMaxNumberOfCharsForNumbers is currently honoured in only one place.

The gap

The configured value reaches MathUtil from exactly one production caller — Validator — so it applies only when someone calls XmlObject.validate(options) explicitly. The path that runs on every parse() is lazy value materialization, XmlObjectBase.check_dated → update_from_wscanon_text → set_text in the value holders, and that always used DEFAULT_MAX_NUMBER_CHARS, because no XmlOptions is reachable from a value holder. Raising or lowering the option had no effect there. Several MathUtil and XsTypeConverter methods also had no maxNumberOfChars overload at all, so there was nothing to pass the value to even where it was in scope.

Approach

Carry the limit on the Locale, exactly as _loadStrictFloatingPoint and _loadAllowDecimalExponent are already carried: a default method on XmlLocale, a field copied from the options in the Locale constructor, and a get_max_number_chars() helper on XmlObjectBase so the holders have one place to read it. Two lines of this idiom were already present at JavaDecimalHolder:46 and JavaFloatHolder:55.

Add the missing overloads so there is something to pass the value to — MathUtil.parseAsBigInteger, parseAsLong, toBigInteger, and XsTypeConverter.lexDecimal, lexInteger, lexLong. lexInt/lexShort/lexByte need none: they use the hand-rolled parseIntXsdNumber/parseShort/parseByte, are bounded by the target type, and never call MathUtil.

Wire it through the decimal, integer and long holders, and through XmlObjectBase.getBigIntegerValue().

Validator needs no change — all integer-derived types route through its BTC_DECIMAL case (note the derivedFromInteger(type) check), which is already wired.

Compatibility

Every new overload is additive, and every existing signature keeps defaulting to DEFAULT_MAX_NUMBER_CHARS. Nothing changes for callers who do not set the option. Callers who do set it get the behaviour the setter has always advertised — worth noting as a behaviour change for anyone who set it and, without knowing it, got no effect on the parse path.

New @since tags are 5.4.1, since 5.4.0 is released.

Not in scope

• GDate / GDuration fractional seconds — the constructors are public API with no options in scope, so wiring them means new public API on two widely-used classes. Still bounded by the 1024 default.
• XMLStreamReaderExtImpl (rich parser) is built from a bare XMLStreamReader with no options; it can pick up the new overloads later.
• Tooling, CLI and schema-compiler sites (PrettyPrinter, Inst2Xsd, SampleXmlUtil, StscTranslator, SchemaTypeLoaderBase, SOAPArrayType, XmlCalendar, XPathFactory, QNameCache) — trusted or hardcoded input.

Verification

MaxNumberOfCharsTest parses a 2000-character number and materializes it. With the main-source changes reverted, its 4 configured-limit tests fail and its 3 default-behaviour tests pass — which is exactly the intended split: the option starts working, and unset behaviour is untouched.

Ran misc.checkin.*, impl.util.* and the values tests locally — 112 pass. Leaving the full suite to CI.

🤖 Generated with Claude Code