[Feature] Replace fastjson with Jackson

[halibobo1205]

Problem Statement

Java-tron currently uses two JSON libraries side by side:

• Jackson (com.fasterxml.jackson) — primarily in the JSON-RPC、eventPlugin、keystore、TVM Trace、Transaction Cache、Peer Persist layer
• fastjson (com.alibaba:fastjson) — primarily in the HTTP API layer

This dual-library situation creates three concrete problems:

1. Maintenance burden — Developers must learn and maintain two distinct serialization APIs (JSONObject / JSONArray vs. ObjectMapper / JsonNode), increasing cognitive overhead and onboarding cost.
2. Security exposure — fastjson has accumulated 20+ CVEs since 2017, including multiple critical RCE vulnerabilities (e.g., autoType bypass chains). The library's development focus has shifted to fastjson2, leaving 1.x in maintenance-only mode.
3. Serialization inconsistency — The HTTP layer and JSON-RPC layer diverge in field ordering, null handling, and type coercion, causing subtle integration issues for downstream API consumers.

Dimension	fastjson	Jackson
Ecosystem reach	Alibaba-centric	Java ecosystem standard (Spring Boot, Quarkus, Dropwizard)
Security track record	20+ CVEs incl. critical RCE	Mature vulnerability handling, well-audited
API richness	Basic parse / serialize	ObjectMapper, JsonNode tree model, streaming API, custom serializers, MixIn, modular extensions
Maintenance	Single-vendor driven	FasterXML org + broad community

Proposed Solution

Replace all com.alibaba.fastjson usages with the existing com.fasterxml.jackson.

Specification

Dependency Changes

• Remove: implementation 'com.alibaba:fastjson:1.2.83' from framework/build.gradle
• Upgrade: jackson-databind from 2.18.3 → 2.18.6 (addresses CVE GHSA-72hv-8253-57qq)

Code Changes

• Replace JSONObject / JSONArray / JSON.parseObject() / JSON.toJSONString() with Jackson equivalents (ObjectMapper, ObjectNode, ArrayNode, JsonNode)
• Introduce Util.MAPPER (shared ObjectMapper singleton) and Util.parseObject() as centralized helpers in Util.java.
• Remove ParserConfig.setSafeMode() from DefaultConfig.java (Jackson is safe by default)
• Migrate all HTTP Servlet classes, ContractEventParserJson, TronJsonRpcImpl, and related test files

API Changes: None — all external JSON output formats remain identical.

Configuration Changes: None.

Protocol Changes: None.

Scope of Impact

• Core protocol
• API/RPC
• Database
• Network layer
• Smart contracts
• Documentation
• Other

Breaking Changes

None. External JSON response formats are preserved.

Backward Compatibility

Fully backward compatible. This is a pure internal refactoring — no external API, configuration, or protocol changes.

Implementation

Do you have ideas regarding the implementation?

1. Centralize a shared ObjectMapper singleton in Util.java with safe defaults (FAIL_ON_UNKNOWN_PROPERTIES = false, etc.).
2. Start with Util.java as the pivot point — most HTTP Servlets delegate JSON operations through it, so converting this file cascades coverage broadly.
3. Migrate each Servlet file, replacing fastjson API calls with Jackson equivalents.
4. Update all corresponding test files.
   Are you willing to implement this feature?

Yes.

Estimated Complexity

Medium — Large volume of files (113+ changed).

Testing Strategy

Test Scenarios

1. All existing HTTP Servlet unit tests pass without regression.
2. All JSON-RPC tests pass without regression.
3. JSON output semantic equivalence verified across all modified API endpoints (field names, value types, null handling, field ordering).
   Performance Considerations

• Jackson's ObjectMapper is thread-safe and designed for singleton reuse — no per-request allocation overhead.
• No performance degradation expected; Jackson is the serialization engine already used by Spring and most Java frameworks at scale.
• Benchmark critical endpoints under concurrent load to confirm no throughput regression.