JEP草案：将JDK移植到Windows/GCC（MSYS2 UCRT64）
OpenJDK发布JEP草案，计划将JDK移植到Windows平台的GCC编译器（MSYS2 UCRT64环境），目前仍处于实验阶段。该提案支持模板解释器、C1/C2 JIT编译器及ZGC/Shenandoah等主流GC，但暂不支持clang和旧版运行时库。主要风险在于GCC缺少JDK依赖的结构化异常处理等功能，代码改动较为侵入性，仍在持续优化中。
Openjdk
OpenJDK，Java 平台标准版的开源实现。
评论
点赞
收藏OpenJDK 出台生成式 AI 使用临时禁令：禁止 AI 生成内容直接入库，但允许私下辅助开发
OpenJDK 发布临时政策：禁止在贡献中直接使用生成式 AI 代码、文本或图像，但允许开发者私下用 AI 辅助理解、调试和审查代码。 该政策针对审查负担、安全风险及知识产权问题，要求 PR 中添加确认框声明合规，并列出 AI 生成内容的识别线索如提交信息中的 Co-Authed-By 标记、过于结构化的评论等。
JEP 538：密码学对象的 PEM 编码标准 API
Java 27 引入 JEP 538，为 PEM 格式（Base64 编码的密钥、证书文本）提供标准 API。新增 PEMEncoder/PEMDecoder 类，支持线程安全的加解密转换，简化了此前需手动解析 Base64 和头尾标记的繁琐工作。同时引入 BinaryEncodable 接口统一标识可编码对象，并增强 EncryptedPrivateKeyInfo 以直接生成 KeyPair。对处理 TLS 证书链、OpenSSH 密钥及硬件令牌交互的开发者是重大便利。
JDK 27 起弃用 macOS x64 端口
Oracle 宣布从 JDK 27 开始弃用 macOS x64 端口并计划移除，原因是 Apple 已全面转向 ARM 架构，维护成本过高。构建时将报错，需显式启用 --enable-deprecated-ports 才能继续编译，且不再保证功能正常。这标志着 Java 在 Intel Mac 上正式进入倒计时。
JEP 540：简易 JSON API（已进入孵化器）
OpenJDK 发布 JEP 540，将轻量级标准 JSON API 纳入孵化器。该提案旨在让 Java 原生支持 RFC 8259 标准的 JSON 解析与生成，无需引入 Jackson 或 Gson 等外部库。API 设计极简，专注于简单任务的数据提取与结构导航，通过 sealed interface 确保类型安全。此举意在降低 Java 处理 JSON 的样板代码，提升在配置管理和快速脚本场景下的开发效率。
JEP 539：JVM 严格字段初始化特性进入预览阶段
JDK 26 将严格字段初始化特性移至预览阶段。该机制要求标记的字段在读取前必须显式初始化，消除了默认值带来的隐蔽 Bug。 这为值类型和空安全字段提供了底层支持，同时允许 JVM 进行更激进的 JIT 优化，提升最终运行性能。
OpenJDK拟弃用macOS x64端口：顺应苹果ARM转型
OpenJDK提出JEP，计划弃用并最终移除JDK对macOS x64架构的支持。原因是苹果硬件已全面转向ARM架构，Oracle工程师将停止维护该端口。 构建系统将默认报错，需显式开启才能编译。此举旨在减少维护负担，顺应硬件平台变迁。
利用 Babylon 框架在 Java 中调用 GPU Tensor Cores
OpenJDK Babylon 项目展示了如何在 Java 中通过 HAT 框架直接调用 NVIDIA GPU 的 Tensor Cores。文章对比了原生 CUDA 与 Java 实现的性能，在 A10 GPU 上实现了从 240 GFLOP/s 到 7.3 TFLOP/s 的加速，同时保持代码在 Apple M4 等设备上的可移植性。 研究重点在于解决 Java 在 AI 和高性能计算领域的硬件加速瓶颈，通过代码反射和 API 抽象，让 Java 开发者能以接近原生的效率利用异构硬件，为 LLM 等负载提供新的优化路径。
OpenJDK Interim Policy on Generative AI
OpenJDK 发布临时政策：禁止在贡献中直接使用生成式 AI 代码、文本或图像，但允许开发者私下用 AI 辅助理解、调试和审查代码。 该政策针对审查负担、安全风险及知识产权问题，要求 PR 中添加确认框声明合规，并列出 AI 生成内容的识别线索如提交信息中的 Co-Authed-By 标记、过于结构化的评论等。