Extend Use{List,Set,Map}Of to recognise prose-statement chains

[steve-aom-elliott]

Summary

UseListOf, UseSetOf, and UseMapOf previously matched only the anonymous-class idiom (new ArrayList<>() {{ add("a"); add("b"); }}). Each recipe now also recognises the much more common prose-statement shape:

// before
List<String> names = new ArrayList<>();
names.add("Bob");
names.add("alice");
names.add("Charlie");

// after
List<String> names = new ArrayList<>(List.of("Bob", "alice", "Charlie"));

The same pattern applies to Set<T>/HashSet (with Set.of(...)) and Map<K,V>/HashMap (with Map.of(k, v, ...) up to 10 pairs, then Map.ofEntries(Map.entry(k, v), ...)).

The output is always wrapped in the mutable ArrayList/HashSet/HashMap so any downstream .sort(), .add(), etc. remain valid. This is the safe choice in all cases; a future enhancement could detect "never mutated after the chain" and shed the wrap.

Recognised shapes (per recipe)

Recipe	Constructor	Method	Output factory
UseListOf	new ArrayList<>()	target.add(arg)	new ArrayList<>(List.of(...))
UseSetOf	new HashSet<>()	target.add(arg)	new HashSet<>(Set.of(...))
UseMapOf	new HashMap<>()	target.put(k, v)	new HashMap<>(Map.of(...)) / new HashMap<>(Map.ofEntries(...)) past 10 pairs

Bail conditions

Each recipe leaves code unchanged when any of the following applies:

• The LHS is a raw type (e.g. List names = new ArrayList()) — we'd be guessing at a type argument. Other recipes can be composed to parameterise first.
• The constructor takes arguments (e.g. new ArrayList<>(10) with a capacity hint) — silently dropping the hint would be misleading.
• Any statement between the declaration and a later add/put isn't itself a recognised call on the same target (e.g. System.out.println(...), addAll(..)).
• An argument references the target variable itself (e.g. target.add(target.size())) — the collapsed List.of(...) would evaluate against the pre-add state and change semantics.
• Any argument is the null literal — List.of / Set.of / Map.of / Map.entry all reject null at runtime.
• Fewer than two add/put statements follow the declaration — the rewrite would be noise.

Implementation

A visitBlock pre-pass scans for prose patterns and records (initializer UUID → [args]) on a cursor message. super.visitBlock then visits children; the existing visitNewClass override consults the message via getCursor().getNearestMessage(...) and, when matched, applies a JavaTemplate at the correct cursor depth (where updateCursor(n) is well-defined). After super.visitBlock returns, a post-pass filters the now-absorbed add/put statements out of the block.

The original anonymous-class logic is preserved verbatim — both shapes are handled by the same recipe class.

Test plan

• UseListOfTest — 7 existing + 7 new: positive prose-chain, single-add below threshold, intervening statement, arg-referencing-target, null arg, raw LHS, capacity-hint constructor.
• UseSetOfTest — 8 existing + 6 new: parallel coverage to UseListOfTest.
• UseMapOfTest — 12 existing + 6 new: positive Map.of, Map.ofEntries boundary at 11 pairs, single-put below threshold, intervening statement, value-referencing-target, null value, raw LHS.
• ./gradlew test passes (full suite, no cross-package regressions).
• ./gradlew recipeCsvValidate passes; recipes.csv regenerated to reflect the new descriptions.

[timtebeek]

Nice extension indeed! Much more common case. Still iterating locally on some readability improvements for map pairs, as all on a single line can hurt readability I think.