2026-08-08 — OpenJDK 封殺 AI 生成程式碼、Postgres 用 Rust 疊出數百倍分析效能、Cloudflare 用 V8 isolate 打造 AI 專用瀏覽器 Kitesurf

OpenJDK 立禁令:AI 寫的程式碼不准進 Java 原始碼庫,儘管甲骨文自己滿口 AI

OpenJDK Legal(openjdk.org)· 政策原訂於 2026 年 4 月,經 The Register(2026-08-03)與 Hacker News(2026-08-08)重新引爆討論

背景

OpenJDK Governing Board 稍早通過一份暫行政策(interim policy),明文禁止社群貢獻中出現任何由生成式 AI 產出的內容。這份文件掛在 openjdk.org/legal/ai,原本在今年稍早就已生效,直到英國科技媒體 The Register 在 2026 年 8 月 3 日重新報導、並在 Hacker News 引發討論後,才又成為工程師圈的話題。政策適用範圍不只是原始碼,還包括 Git repository、GitHub pull request、e-mail、wiki 頁面與 JBS(JDK Bug System)issue 裡的文字與圖片。

核心改動

政策原文寫得很直白:「OpenJDK 社群的貢獻不得包含任何一部分或全部由大型語言模型、diffusion model 或類似深度學習系統生成的內容」。就算只是把 100 行 AI 產生的程式碼手動改掉 10 行,整份貢獻依然算是「部分 AI 生成」,一樣不被接受。實務上,貢獻者要在 Skara(OpenJDK 的自動化 PR 審查系統)裡勾選一個 checkbox,確認自己的貢獻符合這條規定。政策同時留了後門:開發者仍可以私下用生成式 AI 來理解、除錯、審閱 OpenJDK 程式碼或做研究,只是不能把 AI 生成的內容直接送進專案。

影響範圍

OpenJDK 給出的理由有三個:第一是審查者負擔,大量看似合理但實際上錯誤或難以維護的 AI 程式碼會拖垮有限的審查人力;第二是安全性,JDK 是許多關鍵系統的地基,錯誤容忍度必須拉高;第三是智慧財產權——Oracle Contributor Agreement(OCA)要求貢獻者無條件擁有並轉讓程式碼的 IP,但 AI 生成內容的著作權歸屬目前仍是「active litigation」中的爭議問題。有意思的是,同樣隸屬 Oracle 的 GraalVM 專案的 Coding Assistants 政策卻允許 AI 輔助貢獻,兩個專案的立場正好相反,這點在 InfoQ 於 6 月的報導中被特別點出。

這次舊政策被重新翻出來討論,起點是 The Register 那篇標題辛辣的報導,對照了 Oracle 共同創辦人 Larry Ellison 在 2025 年 Oracle AI World 上的說法——「Oracle 寫的程式碼,其實不是 Oracle 寫的,是我們的 AI 模型在寫」——以及共同執行長 Mike Sicilia 稍早強調 AI 工具正讓 Oracle 內部的工程團隊「用更小的團隊做出更完整的產品」。對內大力擁抱 AI 寫程式、對外卻在自家旗艦開源專案封殺 AI 貢獻,這個反差正是 Hacker News 上這輪討論的主要火藥點,也是這則新聞在 8 月 8 日重新被廣泛轉發的原因。

原始來源:OpenJDK Interim Policy on Generative AI、The Register、InfoQ

把 Postgres 查詢引擎用 Rust 重寫一遍:batching、operator fusion 與 SIMD 疊出數百倍分析效能

malisper.me(pgrust 專案作者部落格)· 2026-08-03 發佈,2026-08-07 更新

原本的問題

PostgreSQL 的查詢執行器設計於 1980 年代,當年的假設是磁碟 I/O 才是瓶頸,所以整個執行模型採用「Volcano model」:每個 operator 一次只處理一列(row),透過一連串函式呼叫把資料從下層 operator 拉到上層。這在磁碟慢、CPU 快的年代沒問題,但放到今天,CPU 與記憶體頻寬才是分析型查詢的瓶頸,一列一列呼叫函式的開銷反而變成大問題。作者是 malisper.me 部落格的作者,同時也是把 Postgres 用 Rust 重寫的 pgrust 專案開發者。

採用的方法

文章拆成三個疊加的優化:第一步是batching,把逐列處理改成一次處理 1024 列的批次,減少函式呼叫次數並讓 CPU pipeline 更好發揮;第二步是 operator fusion,把 sequential scan 與 aggregate 這兩個 operator 融合成單一節點,省掉中間結果在 operator 之間複製 buffer 的成本;第三步是 SIMD 向量化,在 ARM64 上用單一指令同時處理多筆資料。三項技術疊加後,執行器從逐列的 Volcano model 一路優化到向量化執行。

實際效果

作者用「加總 5 億個數字」這個查詢做基準測試,結果如下:

專案的 GitHub repo 目前釋出到 v0.2,README 上列出幾個對照 ClickBench 與 sysbench 的數字:在 ClickBench 綜合分數上比 ClickHouse快 18.5%,在 pgrcolumnar 分析工作負載上比 PostgreSQL「快上數百倍」,在 300GB 規模的 sysbench-oltp 唯讀測試上比 PostgreSQL 18.3 高出 30% 的吞吐量。另外還提到一顆直接發出機器碼的 JIT,把編譯時間從約 50ms 壓到約 5µs,並且通過 PostgreSQL regression suite 全部 46,066 項測試。

原始來源:malisper.me、GitHub - malisper/pgrust

Cloudflare 造了一個只給 AI Agent 用的瀏覽器:Kitesurf 靠 V8 isolate 隔離每個分頁

Cloudflare Blog · 2026-08-06,作者 Celso Martinho

背景

Cloudflare 在官方部落格發表 Kitesurf,一個完全跑在 Cloudflare Workers 裡的瀏覽器,目前透過 Browser Rendering(Browser Run)API 免費開放測試。文章開宗明義點出動機:「像 Chromium 這樣的瀏覽器引擎是為人類設計的,不是為 agent」,分頁、像素級渲染這些人類需要的功能,對只需要讀取內容、截圖、操作 DOM 的 AI agent 來說都是不必要的開銷。Kitesurf 反過來針對 token 效率、可擴展性與成本去優化。

核心改動:V8 isolate 當沙箱

Kitesurf 的安全架構建立在 Cloudflare Workers 的 V8 isolate 隔離模型上——這是比容器或虛擬機更輕量的沙箱單位,每個 isolate 只共享底層的 V8 執行環境,彼此之間沒有記憶體或狀態重疊,啟動速度也遠快於開一個完整容器。Kitesurf 把每一次頁面載入都當成不可信輸入,拆成好幾種各司其職的 Worker:Engine Worker 負責處理 CDP(Chrome DevTools Protocol)協定與 session 狀態;PageScript Worker 透過 Dynamic Workers 為每個頁面開一份乾淨的 globalThis 與 DOM 物件;PageRenderer Worker 專門把頁面畫成圖片;SandboxOutbound Worker 則是唯一能發出網路請求的元件。任何一個被惡意頁面攻陷的元件,都無法碰到自己權限以外的資源。

渲染這端用的是 Rust 寫的 Blitz 排版引擎搭配 Firefox 的 Stylo CSS 引擎,兩者都編譯成 WebAssembly(透過 wasm-bindgen)在 Worker 裡執行;因為 Workers 原生不支援 eval,JavaScript 的動態求值改用 Boa 這個 JS engine 處理,文字排版則交給 Parley。整體設計盡量維持無狀態,讓單一 Worker 崩潰時只會退化成空白畫面,而不是整個服務掛掉。

實際效果

Cloudflare 用 14 個網址組成的語料庫,比較 Kitesurf 與 Chromium 的資源消耗中位數:

不過就總耗時(wall-clock time)而言,Chromium 反而快 1.7 到 1.8 倍,Cloudflare 將這歸因於 Chromium 的 JIT 編譯優勢;Kitesurf 贏的是直接決定營運成本的 CPU 與記憶體用量。目前 Kitesurf 已經通過超過 215,000 項 Web Platform Tests,在 CSS、DOM、HTML、selection、SVG 這幾個 agent 最常用到的領域涵蓋率最高,但還不支援影片播放、WebGL 渲染、TLS 指紋偽裝與長時間(數分鐘以上)的登入態 session,團隊表示未來會考慮開源。

原始來源:Cloudflare Blog - Kitesurf