TeamCity On-Premises 2026.2.2 和 2026.1.6 错误修复更新已发布，解决了大量问题，包括安全和性能问题，以及项目版本化设置无法收集新更改、服务器重启后云代理无法匹配、检出规则修订计算缓慢、辅助节点无法获取安全补丁列表等错误。强烈建议安装这些更新以解决安全漏洞。更新还提供了性能改进、更好的集成兼容性、更快更稳定的构建和增强的工作流安全性。同一大版本内的错误修复更新共享数据格式，可无需备份恢复直接升级或降级。升级方法包括使用自动更新功能、从官网下载或拉取 Docker 镜像。

JDK 27 于 2026 年 9 月 15 日发布，JEP 523 取消了 G1 在受限环境回退到 Serial GC 的逻辑，使 G1 成为所有环境的默认垃圾收集器。此前当可用处理器为 1 或物理内存低于 1792 MB 时，JVM 会自动选择 Serial GC。该变化主要影响未显式指定收集器的小型容器，如边车容器、批处理与队列 worker、低流量内部服务、CI/开发容器以及设置分数 CPU 的 Pod。升级前可通过 GarbageCollectorMXBean 识别当前收集器：Serial GC 报告 Copy、MarkSweepCompact，G1 报告 G1 Young Generation 等。G1 的本地内存开销约 43 MB，Serial GC 约 1.7 MB；在 256 MB 容器中占比可达 16%，可能导致 OOM。建议用最小容器规格和代表性负载对比总停顿时间、p99 尾延迟及负载下的 RSS；若 G1 表现更差，可显式设置 -XX:+UseSerialGC。Java 27 非 LTS，但同一默认值将进入下个 LTS，提前评估风险更低。

文章评估 Java 27 默认启用的紧凑对象头（Project Lilliput/JEP 534）在 IntelliJ IDEA 中的实际效果。测试覆盖欢迎页、小型 Spring Petclinic 和大型 IDEA monorepo，对比开启与关闭对象头。结果显示：进程 RSS 无稳定显著下降；堆内对象占用在欢迎页及 Petclinic 约减少 6.3%，monorepo 约减少 8.2%—8.4%；总分配量减少 8.8%—13.0%；GC 次数、耗时和 CPU 在多数组场景下降，IDE 操作耗时略有改善。最低可用 -Xmx 方面，Petclinic 从 400MiB 降至 376MiB（6%），monorepo 从 1888MiB 降至 1568MiB（17%）。结论是紧凑对象头可降低内存开销、分配波动和 GC 压力，并降低堆上限，但不保证 RSS 同步下降或整体提速，仍需分别测量，不应仅因对象头变小而调低 -Xmx。

JetBrains发布第三次DataGrip及数据库工具用户体验调查结果，共1420人参与。整体满意度为84.7%，低于前两次的87.5%和90%，主要因本次通过产品内通知覆盖更多仅使用内置数据库工具的用户，该群体满意度为81.4%，而仅用DataGrip和混合用户分别为87.9%和87.0%。分项满意度：质量与稳定性87.5%，性能79.7%，易用性77.0%，功能完整性80.0%，数据源与SQL方言支持86.2%。AI功能满意度41.6%，51.5%为中立；61%的受访者在JetBrains IDE中使用AI，70%将其用于数据库任务。团队表示将优化性能、易用性、数据库支持及AI代理安全与集成。

Foojay网站上线四个自动化页面：Foojay Television汇总Java相关YouTube频道的最新视频，并过滤Shorts、延迟加载以减少追踪；统计页面展示文章、作者、阅读量等数据；Java会议页面通过世界地图列出即将举行的会议及征稿信息；即将发布页面列出已排期的文章。相关页面均开源，数据由脚本自动抓取或在构建时统计，无需手工维护。

本期Spring周刊介绍了作者在本地Docker中使用kind部署Cloud Foundry的体验，并给出安装cf CLI、创建Spring Boot应用及通过cf push上线的简要步骤。随后汇总了Spring生态近期动态，包括Spring AI中MCP应用富UI渲染与加速RAG嵌入的配方、Spring Boot 3.5停止支持后的Spring Boot 4迁移指南、Spring Boot 4.2候选版对启动性能和升级检查的改进，以及相关新闻和视频资源。

作者在其求职门户中用Gemini解释职位与候选人的匹配度，并提出一条规则：每条结论都必须引用原文中的确切字句，代码在展示给用户前校验这些引文是否真实存在，无引用则不成结论。实现上，他用Java记录类约束模型输出结构（匹配可引用职位与简历原文，缺口只引用职位原文），并写了一个不足十行的校验工具方法，只做小写化、空白归一和首尾标点清理后的包含判断，刻意不做模糊匹配，以免模型改写内容混入。所有校验都针对实际发送给模型的文本，而非数据库字段。未通过校验的结论会被丢弃，并把丢弃条数告知用户；若全部被丢弃则返回错误。文章还说明了隐私字段过滤、AI功能可选启动、30秒超时与每会话限流、输出以纯文本渲染等安全措施，并用伪造的模型响应完成7个无网络的单元测试。作者也坦承局限：引文真实不代表推论成立，缺口只说明简历未写而非人不具备，严格校验会牺牲部分正确结论，解释质量尚未量化评估。

本文总结团队在引入AI编码代理后形成的可复用工作流程，核心是把代理的上下文视为有限预算：一次会话只处理一个任务，用简短的规范文档而非冗长的对话记录来传递决策。流程采用双重契约：规范约束输入，由验收标准派生的测试约束输出，并设置三个由人把关的检查点：批准规范、批准并锁定测试、审阅最终差异。文章强调不能把代理的完成报告当作证据，必须以可执行检查、测试强度和最终差异为准，并防止代理为让构建通过而弱化断言。自动审查循环最多三轮，其余分歧交人决策。只有在单代理流程稳定后才引入子代理和并行工作树，并把评审时间计入计划。团队规则、技能等配置应像代码一样版本化管理，并先从一项可测试的真实中型任务开始试行。

CheerpJ 5.0 正式发布，这是面向浏览器的 WebAssembly 版完整 OpenJDK 发行版。本次更新新增对 Java 21 和 25 的支持，与已有的 Java 8、11、17 一起，按期完成了 2025 年 2 月公布的路线图目标，即到 2026 年底与最新 Java LTS 对齐。新版本还首次为所有支持版本提供完整 JDK 而非仅 JRE，使 javac 和 jshell 能够在浏览器端编译并运行现代 Java 代码，为教育等场景带来新可能。发布的最大技术亮点是实验性的 WasmGC 执行引擎：Java 对象变为 WasmGC 对象，热点代码编译为 WebAssembly，由浏览器垃圾回收器管理内存，有望显著提升启动与运行性能，并简化与 LWJGL 等原生 Wasm 库的交互，为在浏览器中运行含模组的现代版《我的世界》以及 IntelliJ IDEA 等大型应用铺路。该引擎目前以可选方式启用，需较新版本浏览器，暂不建议用于生产环境，稳定版计划随 2027 年初的 CheerpJ 6.0 推出。此外，5.0 还提升了 Java 11/17 兼容稳定性，优化类文件解析、JIT 调优与 JAR 下载性能，并改进拖拽、剪贴板和移动端支持。CheerpJ 可直接运行未修改的大型 Java 桌面程序，支持 Swing/AWT、反射、多线程与自定义类加载器，也可运行 Kotlin、Scala 等 JVM 语言，官方演示包括未经修改的《我的世界》浏览器版与客户端生成 PDF。未来计划包括稳定 Java 25 支持、推出 NPM 包、保持与 Java LTS 最多六个月的同步延迟，以及基于 BrowserPod 内核重建系统调用层。