Fix issue 423 locale aware symbol parsing #441
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Support round-trip format/parse for currency symbols with locale-aware precedence resolution: - Extract leading symbol before digits/separators to handle attached amounts (e.g., $100) - Resolve symbols using explicit currency → locale default → global scan precedence - Preserve currency symbols during normalization to prevent spurious matches - Handle both prefix ($US) and suffix (US$) symbol forms with bidirectional substring matching - Raise ambiguity errors with candidate lists when symbols match multiple currencies - Add comprehensive tests for locale-specific resolution and edge cases 🤖 Generated with Claude Code (https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
…ling Enforce spec requirement that empty/missing symbols fail when explicit currency is set. Replace broad Exception catches with specific IllegalArgumentException, and remove unnecessary defensive try-catch that cannot occur given non-null locale validation. Remove unused Collectors import. 🤖 Generated with Claude Code Co-Authored-By: Claude <noreply@anthropic.com>
sri-adarsh-kumar
changed the title
Enhanced JavaDoc comments for all new helper methods with concrete examples showing: - Symbol extraction behavior across different formats - Precedence-based resolution scenarios (locale default, explicit currency, unique/ambiguous matches) - Matching rules and normalization logic with bidirectional examples - Edge cases and error conditions Removed unused 'providers' parameter from resolveSymbol() method since it only returns an ISO code string - the actual provider-aware currency lookup happens in the caller. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
sri-adarsh-kumar
commented
Nov 3, 2025
moneta-core/src/main/java/org/javamoney/moneta/spi/format/CurrencyToken.java
Outdated
Show resolved
Hide resolved
sri-adarsh-kumar
changed the title
Author
|
@keilw Please review the PR when you get time. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Implements locale-aware currency symbol parsing to fix issue #423. Previously, symbols like
$were rejected as ambiguous even when the locale made the currency unambiguous. The new implementation uses precedence-based resolution (explicit currency → locale default → global scan) with proper error messages for genuinely ambiguous cases.Changes
extractLeadingSymbol()to separate currency symbols from numeric content (handles$100,US$1,234)resolveSymbol()with locale-aware precedence and ambiguity detectionThis change is