[agamal026]

Problem

BootstrapMethod retains arrays supplied to its constructor/setter and exposes the stored array through its getter. A caller can therefore change the object's bootstrap arguments, including the bytes written by dump(), without an explicit update.

Related to BCEL-238. This PR addresses BootstrapMethod argument arrays within the broader issue.

Changes

• Copy the null-normalized setter input and return a copy from the getter. The array-taking constructor uses the existing setter delegation.
• Document array ownership and the explicit getter/edit/setter update path. Preserve null-to-empty behavior, public signatures, and both existing copy implementations.
• Add behavioral regressions for constructor/setter/getter aliases, serialized output, null handling, and read/dump round trips. Update the copy tests to apply and verify real setter updates, so they remain meaningful with a copying getter.

Callers that previously updated arguments by modifying a supplied array or a getter result must now apply those changes with setBootstrapArguments(...).

Validation and proof

Source: 4ec24e4, tree f2d597d840a5b09af42518f21ceeaad8ebdfbf98, based on 0d7c17fb365e4be8e3b66018548e7ebbda0e9507.

Executed on 22 October 2026 with Maven 3.9.11 and OpenJDK 17.0.20 on Linux, targeting Java 8:

Run	Reported	Passed	Failures	Errors	Skipped
Unchanged production with the same regression tests	9	5	4	0	0
Fixed focused tests	9	9	0	0	0
Complete default Maven build	3,090	3,075	0	0	15

The four baseline failures are the constructor, setter, getter, and serialized-output ownership assertions. Both test files are byte-identical between the baseline and fixed runs.

The successful default run completed at 11:56:51 UTC, including coverage, RAT, Japicmp, Checkstyle, PMD, SpotBugs, and Javadoc checks.

Portable reproduction:

mvn '-Dtest=BootstrapMethod*' clean test
mvn

Immutable proof packet with logs, commands, case outcomes, and checksums.

The proof records exact commands, UTC times, source identities, sanitized logs, case counts, and the initial environment failures. This environment needed launchers for the installed JDK's javap, javac, and Javadoc modules. No project test or check was skipped to work around those missing launchers. Local Linux/JDK 17 results do not establish coverage of other operating systems/JDKs or hosted CI execution.

AI disclosure

ChatGPT generated the implementation, tests, documentation, and this description, and coordinated automated review and test execution. Independent AI reviewers checked scope and compatibility; no independent human review is claimed. The commit includes a Generated-by: ChatGPT trailer. The contribution guidelines and ASF Generative Tooling Guidance were reviewed.

[garydgregory]

Hello @agamal026
There are probably array inputs of all kinds all over BCEL where this kind of change could be made. Why here?

[agamal026]

You're right; BootstrapMethod is not the only affected class.

I selected it as a bounded part of BCEL-238: its arguments are a primitive int[], the array-taking constructor delegates to one setter, and there is one getter plus a direct serialization result in dump(). This lets the change cover input and output ownership together without choosing how deeply to copy mutable element objects. The recent copy-independence fix in #516 also prompted inspection of this class, but that fix does not establish a copying policy for its accessors.

A wider change needs contract distinctions. JavaClass.getMethods() returns a live array: Peephole and Helloify replace elements and dump the class without calling setMethods(). Code(Code) explicitly documents shared references. Cloning all array boundaries would change those behaviors.

The selection was a limited ownership change, not a BootstrapMethod-specific user failure or a claim that the other APIs are safe. This PR also changes the existing live-array behavior: callers must use setBootstrapArguments(...) to apply edits. The regression tests show the aliasing and serialized-output difference; they do not settle whether that compatibility change is the preferred project policy.

Would you prefer this as a scoped increment under BCEL-238, or should we first establish which related APIs should return copies versus live arrays?

AI disclosure: This reply was drafted by OpenAI ChatGPT (GPT-6 Astra Pro), with source inspection and separate AI reviews.

[garydgregory]

@agamal026
This feels like change for the sake of change so you can stop here. This type of work can be reviewed at a later date if it proves problematic for an actual application. Especially since there may be unintentional side-effects.