Context / Problem

• Issue: In Regression: Removal of parsing constructor causes 2–3× Slower Java proto parsing for deeply nested messages #24828 , @amishra-u reported a deserialization (parsing) regression for deeply nested Java protos after removal of the parsing constructor, with benchmarks showing ~2–3× slowdown.
• Root cause: PR Refactoring Java parsing (21.x) #10665 removed the optimized parsing constructor and moved parsing to the builder path. That refactor also mitigated CVE‑2022‑3171.
• CVE concern: @esrauchg noted that reintroducing the parsing constructor would re‑introduce CVE‑2022‑3171 (NVD entry), which @amishra-u confirmed was reproducible in the original code path.

Summary of Changes

This PR restores the fast parsing path while keeping CVE guardrails intact:

• Reintroduced parsing constructors for full Java gencode (fast path).
• Added safe extension finalization hook (internalMakeExtensionsImmutable) so generated code can freeze extensions without triggering pre‑22 guardrails.
• Optimization 1: Unknown fields:Lazy initialization remains (no builder unless unknowns are seen).
• Optimization 2: Cache per‑field message parsers in parsing constructor.

Why this stays CVE‑safe

• The CVE is triggered by mutable↔immutable flips during parsing.
• This PR does not change the runtime guardrails added in Refactoring Java parsing (22.x) #10664 on v22.x; parsing constructors now call safe runtime helpers and finalize extensions via the new hook.

Benchmarks

Benchmark used are same as the one defined here #24828 (comment)

Performance (DebugProtobuf, ms/op)

Overall

Mean Latency (DebugProtobuf, ms/op)

Throughput (MB/s)

CVE Clusterfuzz (Runtime + GC pauses)

Notes

• This PR focuses on performance wins without regression risk, no hardcoding, CVE‑safe, and fully backward‑compatible.

Co-authored-by: Anshuman Mishra [email protected]