Summary
PerlOnJava rejects valid transliteration syntax used by Lingua::JA::Numbers 0.05. The transliteration parser incorrectly interprets escaped replacement characters as an invalid +-* range.
Reproduction
The failure was found in CPAN random run 20260921-124328-13959, with regression baseline 0f5febaa8, while testing Lingua::JA::Numbers 0.05.
The smallest reproducer is:
my $x = '';
$x =~ tr[（）＋−×÷][\(\)\+\-\*\/];
The distribution contains the equivalent operation in Lingua::JA::Numbers::ja2num, converting full-width Japanese punctuation and arithmetic symbols to ASCII punctuation.
Under PerlOnJava, both the JVM backend and interpreter backend fail with:
Invalid range "+-*" in transliteration operator
Under standard Perl 5.42.2, the same reproducer succeeds.
CPAN evidence
The standard-Perl oracle passes the complete upstream suite:
All tests successful.
Files=6, Tests=289
Result: PASS
PerlOnJava fails all six test programs because the module cannot be compiled:
t/00-Use.t failed during use
t/01-RoundTrip.t compilation failed
t/02-Manman.t compilation failed
t/03-OO.t compilation failed
t/04-LJN.t compilation failed during import
t/05-KANJI.t compilation failed
Files=6, Tests=4
Failed 6/6 test programs
The later to_string and import failures in t/04-LJN.t are cascading errors after the module failed to load; they are not separate defects.
Expected behavior
PerlOnJava should accept the transliteration operator with bracket delimiters and escaped replacement characters exactly as standard Perl does. The hyphen and asterisk in the replacement list are escaped literal characters, not a character range.
Suspected area
The defect is in transliteration parsing/compilation, specifically handling escaped metacharacters in the replacement operand when the operator uses bracket delimiters and Unicode source text. The parser should preserve \- and \* as literals instead of constructing an invalid +-* range.
Environment and scope
- Distribution:
Lingua::JA::Numbers 0.05
- PerlOnJava backends: JVM and interpreter
- Standard Perl oracle: Perl 5.42.2 on macOS
- Native/XS code: none
- Reverse-dependency analysis: not applicable; this is a pure-Perl distribution
This is a reproducible PerlOnJava parser defect, not a timeout, missing dependency, native-library problem, or platform prerequisite.
Summary
PerlOnJava rejects valid transliteration syntax used by
Lingua::JA::Numbers0.05. The transliteration parser incorrectly interprets escaped replacement characters as an invalid+-*range.Reproduction
The failure was found in CPAN random run
20260921-124328-13959, with regression baseline0f5febaa8, while testingLingua::JA::Numbers0.05.The smallest reproducer is:
The distribution contains the equivalent operation in
Lingua::JA::Numbers::ja2num, converting full-width Japanese punctuation and arithmetic symbols to ASCII punctuation.Under PerlOnJava, both the JVM backend and interpreter backend fail with:
Under standard Perl 5.42.2, the same reproducer succeeds.
CPAN evidence
The standard-Perl oracle passes the complete upstream suite:
PerlOnJava fails all six test programs because the module cannot be compiled:
The later
to_stringand import failures int/04-LJN.tare cascading errors after the module failed to load; they are not separate defects.Expected behavior
PerlOnJava should accept the transliteration operator with bracket delimiters and escaped replacement characters exactly as standard Perl does. The hyphen and asterisk in the replacement list are escaped literal characters, not a character range.
Suspected area
The defect is in transliteration parsing/compilation, specifically handling escaped metacharacters in the replacement operand when the operator uses bracket delimiters and Unicode source text. The parser should preserve
\-and\*as literals instead of constructing an invalid+-*range.Environment and scope
Lingua::JA::Numbers0.05This is a reproducible PerlOnJava parser defect, not a timeout, missing dependency, native-library problem, or platform prerequisite.