Object::Pad BUILD blocks fail to parse in bundled compatibility layer

Start in src/main/java/org/perlonjava/frontend/parser/StatementResolver.java around line 88, where class-adjacent special blocks are dispatched, then inspect CoreOperatorResolver.java around line 262 and the existing parser tests. Run the jperl reproducer on both backends and add project-owned coverage for BUILD parsing, field initialization, and constructor behavior. Done means the focused case and CAD::OpenSCAD tests pass without the misleading method-body error.

Summary

CAD::OpenSCAD 0.14 fails its upstream test suite on PerlOnJava because the bundled Object::Pad compatibility layer does not parse the distribution's BUILD { ... } constructor block. The resulting diagnostic is misleading: Expected '{' after method declaration.

Reproduction

The failure was recorded by CPAN run 20260918-141920-96054, target row:

CAD::OpenSCAD / CAD::OpenSCAD::GearMaker

The target's t/01-OpenSCAD.t and t/02-OpenSCAD-Math.t both fail before running any tests. Loading the dependency directly reproduces it:

jperl -e 'use CAD::OpenSCAD::Math; print "loaded\\n";'
jperl --interpreter -e 'use CAD::OpenSCAD::Math; print "loaded\\n";'

Both backends terminate with:

Expected '{' after method declaration
Compilation failed in require

The smallest relevant source shape is:

use Object::Pad;

class Example {
    field $value;

    BUILD {
        $value = 1;
    }

    method value { return $value }
}

CAD::OpenSCAD::Math contains this exact pattern at its class body: BUILD { ... }, followed by Object::Pad method declarations.

Investigation

Object::Pad is bundled by PerlOnJava (Object::Pad version 0.66 in the bundled compatibility module), and the CPAN log explicitly reports that Object/Pad.pm is bundled. Therefore this is not merely an unavailable native dependency.

The parser currently recognizes these class-adjacent special blocks in StatementResolver:

CHECK, INIT, UNITCHECK, BEGIN, END, ADJUST

BUILD is absent from that dispatch at src/main/java/org/perlonjava/frontend/parser/StatementResolver.java around line 88. It consequently falls through as an ordinary expression. When parsing continues into the following method, the token is routed through CoreOperatorResolver.parseAnonymousMethodExpression(), which throws Expected '{' after method declaration at the check around line 262. The error points at the recovery path rather than the actual unsupported BUILD construct.

The same failure occurs on the JVM and interpreter backends. The archived CPAN run used the normal JVM backend and reports both upstream test programs failing with zero tests run.

Expected behavior

PerlOnJava's bundled Object::Pad compatibility should accept BUILD { ... } in a class body and execute it during object construction, or emit a clear supported-feature diagnostic if the feature is intentionally unavailable. Since Object::Pad is bundled and advertised as supported class syntax, the compatibility layer should support this constructor form.

Acceptance criteria

• Parse and execute BUILD { ... } in a bundled Object::Pad class.
• Preserve field initialization and constructor parameter behavior.
• Pass the focused reproducer on both JVM and interpreter backends.
• Add permanent project-owned regression coverage.
• Re-run CAD::OpenSCAD 0.14 tests, especially t/01-OpenSCAD.t and t/02-OpenSCAD-Math.t.
• Improve the diagnostic or parser recovery so malformed/unsupported constructor blocks do not report a misleading method-body error.

Environment note

The archived PerlOnJava run selected Object-Pad-0.825 as the dependency, while PerlOnJava used its bundled compatibility implementation. A clean system-Perl comparison could not be completed in the investigation environment because Object::Pad was not installed and CPAN network access was unavailable. This does not affect attribution: the same source construct reproduces deterministically in both PerlOnJava backends, and the parser source identifies the missing BUILD dispatch.