JVM backend rejects valid @$ glob dereference under strict vars

[fglock]

Summary

The JVM backend rejects valid Perl glob dereference syntax @$ while compiling SOAP::Lite 1.27. This prevents ResourcePool::Resource::SOAP::Lite 1.0103 from loading.

Reproduction

use strict;
die @$;

Commands:

./jperl -e 'use strict; die @$;; print "ok\n"'
./jperl --interpreter -e 'use strict; die @$;; print "ok\n"'
perl -e 'use strict; die @$;; print "ok\n"'

Observed results:

• JVM backend: Global symbol "@$" requires explicit package name (did you forget to declare "my @$"?)
• Interpreter backend: does not report the parser/strict-vars diagnostic; it reaches the require/die behavior.
• System Perl 5.42.2: accepts the syntax.

The minimal form used by the dependency is:

eval "require $class" or die @$;;

Root cause

Perl's parser treats @$ as a glob dereference. perl -MO=Concise shows the operation as rv2av over gv[*$]; it is not a scalar variable whose name is empty. The JVM compilation path instead treats the $ operand as an ordinary undeclared scalar and applies strict-vars validation, producing the false Global symbol "@$" error. The failure is therefore in JVM-path parsing/AST lowering or strict-vars handling for the special glob-dereference form.

CPAN failure

Run 20260908-125510-82561, target ResourcePool::Command::SOAP::Lite::Call, distribution ResourcePool-Resource-SOAP-Lite-1.0103.

All three target test programs fail before running assertions because SOAP::Lite cannot compile:

Global symbol "@$" requires explicit package name ... SOAP/Lite.pm line 2346
Compilation failed in require

System Perl successfully loads the same SOAP::Lite 1.27 source. Its t/02FactorySingleton.t and t/30SOAP.t pass. t/40CallCmd.t could not be used as complete oracle evidence because its historical external fixture host www.fatalmind.com is unavailable in the test environment.

Expected behavior

The JVM backend should accept and correctly compile/evaluate @$ with the same semantics as system Perl and the interpreter backend, including when it appears under use strict in a dependency.

Suggested regression coverage

Add a project-owned unit test covering @$ under use strict, plus the eval "require $class" or die @$ form, and require both JVM and interpreter backends to pass.