北京
當你為了從一個天氣API返回的JSON里提取幾天的溫度數據，就不得不把整個Jackson或Gson拖進項目，這樣的日子或許快要到頭了。OpenJDK最近提出的JEP 540，直接瞄準了這個痛點——讓JDK自己就能解析和生成JSON，不需要任何外部庫。這項名為Simple JSON API的提案目前已進入孵化器階段，它要解決的就是那些被過度設計的簡單任務。
按照設計，這個API只嚴格對標RFC 8259，不提供多配置解析、語法擴展、數據綁定或者流式處理。換句話說，它不打算取代Jackson、Gson、Jakarta JSON Processing、Fastjson 2這些已經非常成熟的庫，而是想補上Java平臺的一塊空白：當你的需求僅僅是“從這個JSON里拿出那個字段的值”時，不用再為了一個簡單操作引入整個庫的依賴。
正方觀點很直接：Python和Go里幾行代碼就能完成的事情，Java沒理由非要寫一堆樣板代碼。JEP 540給出的示例場景頗為典型——計算美國國家氣象局REST API返回的預報溫度平均值。在這種已知JSON結構的情況下，一套標準、低儀式感的API能讓代碼自己的結構就成為一種“事實上的模式”，可讀性大幅提高。
反方并不缺依據：Jackson的成熟度和功能豐富度已經讓它成為事實標準，Gson和Fastjson各有擁躉，為什么還要在JDK里再塞一個？更何況一個只支持RFC 8259的簡潔庫，面對現實世界里花樣百出的JSON擴展語法、流式處理需求，會不會不夠用？
然而JEP 540的定位恰恰繞開了這場爭論。它的非目標就是不去取代任何現有的外部庫，而是給那些并不需要高級特性的場景一個官方、零依賴的選擇。它還特意強調了探索性使用——我們在不熟悉文檔結構時常常需要快速試錯，API就應該快速失敗并給出清晰的錯誤信息，而不是默默容忍異常。同時，對缺失或意外值的彈性處理也寫進了目標，以應對JSON結構隨服務演進而變化的情況。
更值得留意的是，這個提案還明確了一個方向：讓JDK自身具備解析和生成JSON的能力。這意味著未來JDK內部的組件也可以直接使用這套API，而不用反過來依賴外部庫。從平臺演進的角度看，這比單純的“又一個JSON庫”更有分量。JEP 540現在還在孵化器中，但按照Java的流程，一旦順利畢業，那些輕量JSON處理任務或許真能告別引入第三方庫的慣性。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
