Java News Roundup: Simple JSON API, GlassFish, Jakarta EE, JNoSQL, Open Liberty, LangChain4j

{"title_zh":"Java 2026 年 8 月动态：从 JDK 28 的 Simple JSON API 到 Jakarta EE 12","body_zh":"# Java 2026 年 8 月动态：从 JDK 28 的 Simple JSON API 到 Jakarta EE 12\n\n本期 Java 动态的主线很清晰：平台正在继续减少常见任务的额外依赖，同时企业 Java、云原生运行时和 AI 应用框架各自推进版本演进。来源摘要提到的重点包括：Simple JSON API 计划作为 JDK 28 的目标候选、Jakarta EE 12 更新、2026 年 8 月版 Open Liberty、LangChain4j 的小版本发布，以及 Eclipse JNoSQL、GraalVM Native Build Tools、GlassFish 和 Groovy 的新版本。\n\n这些消息未必要求团队立刻升级生产环境，但很适合用来重新检查一件事：哪些能力仍然依赖第三方库，哪些能力已经可以交给平台；哪些版本更新值得试验，哪些应该等待兼容性验证。\n\n## Simple JSON API：标准库可能补上一个长期缺口\n\n来源摘要称，Simple JSON API 被提出作为 JDK 28 的目标。这里的关键词是“目标”，而不是已经发布的最终 API。它说明 Java 平台正在认真考虑为 JSON 的基础处理提供更直接的标准能力。\n\n对应用开发者来说，价值不只是少写几行依赖配置。一个更稳定、范围明确的标准 JSON API，可能带来以下变化：\n\n- 小型命令行工具和基础设施程序不必为了简单 JSON 读写引入完整生态。\n- JDK、框架和构建工具之间的默认行为更容易保持一致。\n- 面向长期维护的库可以减少对某个 JSON 实现细节的绑定。\n- 模块化应用和原生镜像构建时，依赖边界可能更容易审查。\n\n不过，在 API 正式定稿并进入目标 JDK 之前，不应把它当作生产代码的既定契约。复杂的序列化规则、性能调优、Schema 校验和框架集成仍然可能需要成熟的第三方库。\n\n下面是一个不依赖具体候选 API 名称的实践示例。它展示了当应用只需要调用 HTTP JSON 接口时，如何把传输层、JSON 解析层和业务层分开。解析部分使用占位函数，便于未来替换成 JDK 标准 API 或现有 JSON 库。\n\njava\nimport java.net.URI;\nimport java.net.http.HttpClient;\nimport java.net.http.HttpRequest;\nimport java.net.http.HttpResponse;\n\npublic class JsonClientExample {\n public static void main(String[] args) throws Exception {\n HttpClient client = HttpClient.newHttpClient();\n HttpRequest request = HttpRequest.newBuilder()\n .uri(URI.create("https://api.example.test/items/42"))\n .header("Accept", "application/json")\n .GET()\n .build();\n\n HttpResponse<String> response = client.send(\n request, HttpResponse.BodyHandlers.ofString());\n\n if (response.statusCode() / 100 != 2) {\n throw new IllegalStateException(\n "Unexpected HTTP status: " + response.statusCode());\n }\n\n String json = response.body();\n System.out.println("Received JSON: " + json);\n // Replace this boundary with the selected JSON implementation.\n // Item item = Json.parse(json, Item.class);\n }\n}\n\n\n可以这样实践：先把 JSON 解析集中在少数 adapter 类中，不要让业务代码到处调用具体库。这样即使候选标准 API 的形状发生变化，也只需调整边界代码，而不必重写整个领域层。\n\n## 企业 Java 的几条更新线\n\nJakarta EE 12 的更新值得和 Open Liberty、GlassFish 9.0 的第三个里程碑版本放在一起观察。它们分别代表规范演进、云原生运行时实现和兼容性验证的重要节点。\n\nOpen Liberty 的 2026 年 8 月版本面向持续交付场景，适合关注启动行为、容器镜像、运行时配置和 Jakarta EE 功能组合的团队。GlassFish 9.0 的第三个里程碑则更接近开发和验证阶段。里程碑版本可以用于尽早发现迁移问题，但不应自动等同于生产稳定版本。\n\n升级企业 Java 平台时，建议把验证拆成三个层次：\n\n1. 用现有应用执行 API 和部署 smoke test，确认类加载、注入、事务和安全配置没有变化。\n2. 在目标运行时上执行集成测试，重点检查数据库连接池、消息系统、HTTP 客户端和定时任务。\n3. 用接近真实流量的测试检查内存占用、启动时间、请求延迟和日志格式。\n\n一个最小的容器验证流程可以这样写：\n\nbash\n#!/usr/bin/env bash\nset -euo pipefail\n\nIMAGE="my-service:jakarta-ee12-test"\ndocker build --pull -t "$IMAGE" .\ndocker run --rm -d --name jakarta-ee-smoke -p 8080:8080 "$IMAGE"\n\ncleanup() { docker rm -f jakarta-ee-smoke >/dev/null 2>&1 || true; }\ntrap cleanup EXIT\n\nfor attempt in {1..30}; do\n if curl --fail --silent http://localhost:8080/health >/dev/null; then\n echo "health check passed"\n exit 0\n fi\n sleep 2\ndone\n\necho "health check failed" >&2\nexit 1\n\n\n实际项目中需要把镜像启动命令、健康检查路径和端口替换成应用自身的约定。\n\n## JNoSQL、GraalVM 和 Groovy：工具链在补齐细节\n\nEclipse JNoSQL 的维护版本说明 Jakarta NoSQL 相关生态仍在持续修整。对于使用文档数据库、键值存储或多模型数据库的团队，维护版本通常更值得从兼容性和缺陷修复角度评估，而不是只看新增功能列表。\n\nGraalVM Native Build Tools 的维护版本则直接关系到原生镜像构建链。升级时应重点检查反射、资源文件、代理配置和框架生成的元数据，因为这些问题往往在 JVM 模式测试中不会暴露。可以把原生构建放进 CI：\n\nbash\n./mvnw -Pnative -DskipTests=false verify\n# 或 Gradle 项目：\n./gradlew nativeCompile test\n\n\nGroovy 6.0 的第二个 beta 版本适合语言和构建脚本作者做早期兼容性测试。beta 版本的测试价值在于提前发现语法、编译器或插件适配问题，生产发布仍应等待项目自身的稳定性标准。\n\n## LangChain4j 小版本：AI 集成也需要版本纪律\n\nLangChain4j 的 point release 看似变化较小，但 AI 应用的依赖边界往往比普通 Web 服务更复杂：模型供应商 SDK、向量数据库客户端、嵌入模型、提示词模板和工具调用协议可能同时参与运行。\n\n升级这类依赖时，应把以下内容纳入回归测试：\n\n- 同一个提示词的输出结构是否仍满足 JSON Schema 或业务解析器要求。\n- 工具调用失败时，重试和超时是否保持原有策略。\n- token 使用量、请求延迟和模型供应商错误是否发生变化。\n- 流式响应、记忆组件和检索结果的排序是否仍符合预期。\n\n可以用一个明确的配置边界管理模型调用参数，避免把版本升级和业务提示词修改混在同一次变更中：\n\njava\nrecord ChatSettings(String model, double temperature, int maxTokens) {}\n\npublic final class AiService {\n private final ChatSettings settings;\n\n public AiService(ChatSettings settings) {\n this.settings = settings;\n }\n\n public String answer(String question) {\n // Bind LangChain4j at this boundary and keep domain code independent.\n return "model=" + settings.model() + ", question=" + question;\n }\n}\n\n\n这段代码是一个最小的边界示例，具体的 LangChain4j 模型和 chat memory API 应按照项目采用的版本接入。\n\n## 采用建议：按风险分层，而不是追逐版本号\n\n这期版本信息可以转化为一份务实的评估顺序：\n\n- 现在就能做：为 JSON、运行时、原生构建和 AI 调用建立依赖边界与回归测试。\n- 适合试验：在隔离分支或测试环境评估 JDK 28 的 Simple JSON API 候选方向、Open Liberty 新版本和 LangChain4j point release。\n- 需要谨慎：把 GlassFish 9.0 milestone、Groovy 6.0 beta 直接用于生产，或在没有原生镜像测试的情况下升级 GraalVM 构建工具。\n- 升级前必须记录：JDK 版本、Jakarta EE API、运行时实现、构建插件、数据库驱动和 AI 供应商 SDK 的完整组合。\n\nJava 生态的变化正在从“大版本一次性迁移”转向多个相互关联的小步演进。团队最有效的应对方式不是同时更新所有组件，而是先建立可重复的构建和验证流程，再根据应用边界逐项升级。","title_en":"Java News Roundup for August 2026: Simple JSON API, Jakarta EE 12, and Modern Runtime Tooling","body_en":"# Java News Roundup for August 2026: Simple JSON API, Jakarta EE 12, and Modern Runtime Tooling\n\nThis Java roundup points to a common direction: the platform is reducing friction around everyday tasks while enterprise runtimes, cloud-native tooling, and AI libraries continue to evolve independently. The reported highlights include a Simple JSON API proposed as a target for JDK 28, an update on Jakarta EE 12, the August 2026 Open Liberty release, a LangChain4j point release, maintenance releases for Eclipse JNoSQL and GraalVM Native Build Tools, the third milestone of GlassFish 9.0, and the second beta of Groovy 6.0.\n\nThe practical question is not whether every team should upgrade immediately. It is which dependencies can be isolated, which releases are ready for production, and which are better treated as compatibility experiments.\n\n## Simple JSON API: A Potentially Smaller Platform Baseline\n\nThe source summary describes Simple JSON API as a proposed target for JDK 28. “Target” matters here: it should not be treated as a finalized production contract yet. Still, the proposal signals interest in giving Java a more direct standard mechanism for basic JSON work.\n\nA narrowly scoped standard API could help small command-line tools and infrastructure services avoid adding a full JSON stack for simple payloads. It could also give libraries a more predictable platform boundary and make dependency review easier in modular or native-image applications.\n\nMature third-party libraries will likely remain important for advanced serialization rules, schema validation, performance tuning, and framework integration. A sensible design today is to keep JSON handling behind an adapter instead of spreading implementation-specific calls through business code.\n\nThe following example shows that boundary. The transport code is complete; the parsing call is deliberately a placeholder because the candidate API details are not specified in the supplied material.\n\njava\nimport java.net.URI;\nimport java.net.http.HttpClient;\nimport java.net.http.HttpRequest;\nimport java.net.http.HttpResponse;\n\npublic class JsonClientExample {\n public static void main(String[] args) throws Exception {\n HttpClient client = HttpClient.newHttpClient();\n HttpRequest request = HttpRequest.newBuilder()\n .uri(URI.create("https://api.example.test/items/42"))\n .header("Accept", "application/json")\n .GET()\n .build();\n\n HttpResponse<String> response = client.send(\n request, HttpResponse.BodyHandlers.ofString());\n\n if (response.statusCode() / 100 != 2) {\n throw new IllegalStateException(\n "Unexpected HTTP status: " + response.statusCode());\n }\n\n String json = response.body();\n System.out.println("Received JSON: " + json);\n // Replace this boundary with the chosen JSON implementation.\n // Item item = Json.parse(json, Item.class);\n }\n}\n\n\nThis is a practical migration tactic: centralize parsing now, then change one adapter when the standard API is finalized or when the project chooses to adopt it.\n\n## Enterprise Java Moves in Parallel\n\nThe Jakarta EE 12 update is best considered alongside the August Open Liberty release and GlassFish 9.0’s third milestone. They represent different points in the ecosystem: specification evolution, a cloud-oriented runtime distribution, and an early implementation milestone.\n\nOpen Liberty users should examine runtime configuration, container images, startup behavior, and the Jakarta EE feature set used by their applications. GlassFish milestone builds are useful for early compatibility testing, but a milestone label is not a production-readiness guarantee.\n\nA controlled upgrade should cover three layers:\n\n1. Run API and deployment smoke tests against the existing application.\n2. Execute integration tests for dependency injection, transactions, security, database pools, messaging, and scheduled jobs.\n3. Measure startup time, memory, latency, and log behavior under representative load.\n\nA minimal container smoke test can be automated as follows:\n\nbash\n#!/usr/bin/env bash\nset -euo pipefail\n\nIMAGE="my-service:jakarta-ee12-test"\ndocker build --pull -t "$IMAGE" .\ndocker run --rm -d --name jakarta-ee-smoke -p 8080:8080 "$IMAGE"\n\ncleanup() { docker rm -f jakarta-ee-smoke >/dev/null 2>&1 || true; }\ntrap cleanup EXIT\n\nfor attempt in {1..30}; do\n if curl --fail --silent http://localhost:8080/health >/dev/null; then\n echo "health check passed"\n exit 0\n fi\n sleep 2\ndone\n\necho "health check failed" >&2\nexit 1\n\n\nReplace the image name, startup contract, health endpoint, and port with the conventions used by the application.\n\n## Maintenance Releases and Build Boundaries\n\nThe Eclipse JNoSQL maintenance release is relevant to teams using Jakarta NoSQL and database-specific integrations. Maintenance work should be evaluated primarily through compatibility tests and defect fixes, not only through headline features.\n\nGraalVM Native Build Tools updates deserve focused attention because native images expose problems that ordinary JVM tests may miss. Reflection, resource files, proxy definitions, and generated metadata should all be covered in CI:\n\nbash\n./mvnw -Pnative -DskipTests=false verify\n# For Gradle projects:\n./gradlew nativeCompile test\n\n\nGroovy 6.0 beta 2 is a reasonable test target for language and build-script authors who want to find compatibility problems early. Beta software can reveal useful compiler, syntax, and plugin issues, but production adoption should follow the project’s own stability criteria.\n\n## LangChain4j: Small Version Changes Still Need AI Regression Tests\n\nA point release in LangChain4j may look modest, but an AI service commonly combines a model provider SDK, embeddings, a vector store, prompt templates, and tool-calling behavior. A dependency update can therefore affect more than compilation.\n\nRegression tests should check structured output, JSON schema compliance, timeout and retry behavior, token usage, latency, provider errors, streaming responses, memory components, and retrieval ordering. Keep model configuration behind a small boundary so a library upgrade does not become entangled with prompt changes.\n\njava\nrecord ChatSettings(String model, double temperature, int maxTokens) {}\n\npublic final class AiService {\n private final ChatSettings settings;\n\n public AiService(ChatSettings settings) {\n this.settings = settings;\n }\n\n public String answer(String question) {\n // Bind LangChain4j at this boundary.\n return "model=" + settings.model() + ", question=" + question;\n }\n}\n\n\nThis is a deliberately minimal boundary example. Bind the concrete LangChain4j model and memory APIs according to the version selected by the project.\n\n## A Practical Adoption Checklist\n\nThis roundup can become a useful upgrade sequence: establish dependency boundaries and repeatable regression tests now; evaluate the JDK 28 JSON direction, Open Liberty, and LangChain4j in isolated environments; and treat GlassFish milestones and Groovy beta builds as compatibility targets rather than automatic production upgrades.\n\nBefore changing versions, record the full combination of JDK, Jakarta EE APIs, runtime, build plugins, database drivers, and AI provider SDKs. Java’s ecosystem is increasingly moving through many coordinated small changes instead of one large migration. Teams that can reproduce builds and validate behavior component by component will have more room to adopt the useful parts without turning every release into a platform-wide event.","seo_description_en":"A practical Java roundup covering the proposed JDK 28 Simple JSON API, Jakarta EE 12, Open Liberty, LangChain4j, GraalVM tooling, GlassFish, and Groovy."}