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

Start with jperl t/02-known.t and jperl --interpreter t/02-known.t, then inspect Geo::Coordinates::OSGB.pm and the JVM and interpreter handling of constant hash-reference dereferences. Use the affected tests, including 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, and t/13-edge-and-at-sea.t. Done means a focused regression test covers exists and array dereferences, both backends pass all 360 upstream tests, and ordinary variables and constant return types remain intact.

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