JetBrains 发布文章比较 RustRover 与 VS Code + rust-analyzer 两种 Rust 开发环境。VS Code 是通用编辑器，通过 rust-analyzer 扩展提供 Rust 补全、诊断、导航和重构；配置灵活，可扩展任务、启动配置和调试器。RustRover 是专业 Rust IDE，使用 JetBrains 自研分析引擎并集成 Cargo 项目模型，内置测试、调试、重构、数据库和版本控制等支持。文章对比二者在代码分析、导航、运行 Cargo、测试、调试、检查和重构方面的差异，也介绍 AI 辅助开发能力。RustRover 适合希望在同一项目模型下使用完整工具链的开发者，VS Code 更适合偏好轻量、自定义多语言环境的用户。文中还提供从 VS Code 迁移到 RustRover 的五步指南。

文章探讨为何JVM集群中的每个实例都必须独立完成预热。JIT编译产出的机器码并非字节码的简单翻译，而是针对特定JVM某一时刻状态的“下注”，因此无法仅凭方法全限定名直接复制使用。要迁移已编译代码，必须解决三大难题：身份识别（类名并非唯一标识，需结合类加载器，并从已知实体逐级推导句柄）、有效性验证（每个方法包含数千条依赖假设且须全部成立，同时验证成本必须远低于本地重新编译）、盈利性（代码可能完全正确却不适合当前实例，因为编译代码还包含行为统计假设，而新实例尚无性能画像）。作者指出Project Leyden通过提前生成AOT缓存来规避部分问题，而另一方案则尝试将生产环境JVM中正在运行的编译代码流式传输到仍在启动的实例。本文为系列第一部分。

本期 Bootiful 播客中，主持人对话 JReleaser 创建者、Java 冠军 Andres Almiray，畅谈桌面 Java 的未来、Electron 的痛点与 JavaFX 的优雅，以及让 Java 应用更易交付的工具链。对话重点介绍 JReleaser：它可帮助 Java 项目发布版本、打包原生安装器、生成分发包、计算签名与校验和、向社交平台发布公告，并自动化 GitHub、GitLab、Maven Central 等平台的发布流程。两人还讨论 JReleaser 如何与 JLink、JPackage 配合，为何成为 JBang 等项目的关键工具，以及它如何让 Java 分发重新变得现代。适合关注软件打包、发布和开发者体验的听众。

Lathe 是由开发者 Alexey Gavrilov 打造的开源 Java 语言服务器，采用 Apache 2.0 许可。它不再通过读取构建文件去猜测项目结构，而是借助 Maven 构建扩展在构建过程中直接捕获类路径、模块路径、注解处理和测试配置，并在每次构建时自动刷新，从而保证编辑器与真实编译结果始终一致。功能覆盖代码智能（自动导入补全、跳转定义与声明、查找引用、调用与类型层次、符号搜索、签名帮助、Javadoc 悬浮提示、语义高亮等）、诊断与重构（javac 错误警告、未使用成员提示、快速修复、google-java-format）、运行测试与调试，以及类、接口、记录、枚举等代码脚手架生成。目前支持 Neovim（客户端最完整）和 Emacs（内置 Eglot），VS Code 客户端在规划中。使用需 Java 21+ 与 Maven 3.x，初始化只需注册扩展、执行一次构建并配置编辑器。

软件开发者、UX/UI设计师兼技术作者Libán Bande González发布新书《Skinning JavaFX Applications》，这是一本以代码为核心的实用指南，讲解如何构建现代化、视觉独特的JavaFX界面。作者指出，仅靠CSS无法让JavaFX应用呈现Microsoft或JetBrains风格的外观，因此本书重点介绍Control-Skin架构，帮助开发者创建自定义控件与皮肤。内容涵盖自定义窗口边框、运行时主题切换、Mica与Acrylic等Fluent Design材质效果，以及一整套微交互实现。本书基于作者多年开发真实桌面商业管理应用的经验，适合希望提升JavaFX界面表现力的开发者参考。

JetBrains创业项目“Small Talk”采访Synnax联合创始人兼CEO Emiliano Bonilla。Synnax是面向硬件测试与运行的任务控制与数据平台，用于火箭发动机测试等高风险场景，替代电子表格和20TB级无序文件堆积。因Excel和Python难以满足实时控制需求，团队约六个月自研实时编程语言Arc。公司正从航天拓展至量子计算低温控制、油气和制造业。团队使用GoLand、CLion、PyCharm及Claude Code。Bonilla强调任务关键软件需在速度与质量间平衡，未来重点包括自动化数据审查与异常检测。

Kotlin正在扩展伴生机制，计划从2.5.0版本起引入实验性的伴生块（companion block）与伴生扩展（companion extension）。伴生块在语法上接近伴生对象，但编译方式发生根本变化：在JVM上编译为静态成员，在Kotlin多平台中可定义expect伴生成员并用含静态成员的Java类实现。伴生扩展则允许为任意类或接口声明新的类成员，无论是自有代码还是Java或第三方代码。使用时需添加-Xcompanion-blocks或-Xcompanion-blocks-and-extensions编译器标志，后者会产生预发布二进制，导致使用伴生扩展的库暂时无法作为依赖被消费。伴生对象仍是Kotlin的完整组成部分，无需迁移；若改用伴生块，多数情况下只需移除object关键字并重新编译，但相关项目及依赖代码需一同重新编译。

作者回顾了自己与Java代码格式化工具的长期纠葛：从Sun/Oracle代码规范，到难以接受的Google风格，再到使用Terraform与Go后体会到的自由。加入一个以google-java-format作为CI质量门的项目后，他从最初厌烦转为离不开，随后又发现了布局更紧凑、对响应式代码支持更好的palantir-java-format。但这两个项目维护乏力，新Java版本不断发布，issue与PR却长期停滞。AI编码代理进一步放大了问题：每个模型和会话都有自己的代码风格，常产生大量空白噪音diff，与CI反复拉锯。为此作者fork了Palantir仓库，推出open-java-format，提供IntelliJ插件、Gradle集成与各平台原生二进制，将CI迁移至GitHub Actions，加入产物签名与Java 27支持，并修复了若干恼人缺陷。2.98.0.x系列基于palantir-java-format 2.98.0。后续计划以开源方案替换自定义依赖、修复Error Prone问题，并用该格式化器全面自举。

Codename One 近期更新聚焦性能与开发体验：优化垃圾回收、地图、启动时间及 JavaScript 开销，并新增原生拖放和跨设备连续性功能。同时，Javadoc 已加入网站搜索。