Geo::Coordinates::OSGB 2.20 fails on constant hash-reference dereferences

まず jperl t/02-known.t と jperl --interpreter t/02-known.t から始め、次に Geo::Coordinates::OSGB.pm と、定数ハッシュ参照のデリファレンスに対する JVM およびインタープリターの処理を調査します。t/02-known.t、t/03-format.t、t/05-random.t、t/06-osgb-grid-to-ll.t、t/06-osgb-ll-to-grid.t、t/08-out_of_range.t、t/13-edge-and-at-sea.t を含む、影響を受けるテストを使用します。exists と配列のデリファレンスをカバーする焦点を絞った回帰テストがあり、両方のバックエンドが 360 件すべての upstream テストに合格し、通常の変数と定数の戻り値型がそのまま維持されれば完了です。

Summary

Geo::Coordinates::OSGB v2.20 fails most of its upstream test suite under PerlOnJava when code dereferences the hash reference returned by a use constant declaration:

use constant ELLIPSOIDS => { ... };
my $shape = ...;
my ($a, $b, $f, $e2) = @{ ELLIPSOIDS->{$shape} };

This was observed in CPAN random tester run 20260914-160652-26153.

Reproduction

The upstream suite passes completely under system Perl:

• 10 test programs
• 360 tests
• all tests successful

Under PerlOnJava, the failure reproduces on both execution backends. Focused reproductions are:

jperl t/02-known.t
jperl --interpreter t/02-known.t

Observed failures

JVM backend:

Global symbol "@ELLIPSOIDS" requires explicit package name (did you forget to declare "my @ELLIPSOIDS"?)

The error is reported from Geo::Coordinates::OSGB.pm at the ELLIPSOIDS->{$shape} dereference.

Interpreter backend:

Can't use string ("0") as a HASH ref while "strict refs" in use

The affected upstream programs include:

• t/02-known.t
• t/03-format.t
• t/05-random.t
• t/06-osgb-grid-to-ll.t
• t/06-osgb-ll-to-grid.t
• t/08-out_of_range.t
• t/13-edge-and-at-sea.t

Some tests that do not exercise the affected coordinate-conversion paths pass, including t/01-load.t, t/04-parsing.t, and t/07-maps.t.

Expected behavior

Perl treats the value declared by use constant ELLIPSOIDS => { ... } as a hash reference. The expression ELLIPSOIDS->{$shape} must resolve the constant value and perform a normal hash lookup under both PerlOnJava backends, matching system Perl.

Technical evidence and diagnosis

The distribution is pure Perl and has no XS, native-library, network, display, or platform-specific prerequisite involved in the failing tests. System Perl passes all 360 upstream tests, while PerlOnJava fails deterministically during compilation/execution on both backends.

The relevant source contains:

use constant ELLIPSOIDS => {
    WGS84  => [ ... ],
    ETRS89 => [ ... ],
    GRS80  => [ ... ],
    OSGB36 => [ ... ],
};

and repeatedly uses expressions such as:

exists ELLIPSOIDS->{$shape}
@{ ELLIPSOIDS->{$shape} }

The JVM frontend appears to parse the bareword constant as a package variable and performs strict-vars validation against an array symbol named @ELLIPSOIDS. The interpreter instead evaluates the constant call incorrectly and attempts to dereference the string value "0" as a hash reference. This suggests a shared semantic gap in constant subroutine resolution or bareword/hash-dereference handling, with backend-specific failure paths.

Acceptance criteria

• All 10 upstream test programs and 360 tests pass on the JVM backend.
• The same suite passes on the interpreter backend.
• Add a project-owned focused regression test for hash-reference constants used through bareword dereference syntax, including exists CONSTANT->{key} and @{ CONSTANT->{key} } cases.
• Preserve behavior for ordinary package variables and other constant return types.

Environment

• PerlOnJava CPAN run: 20260914-160652-26153
• Distribution: Geo-Coordinates-OSGB-2.20
• System Perl: full upstream suite passes
• Affected backends: JVM and interpreter