Foojay 每天发布多篇文章，需要分别分享到 Mastodon、Bluesky 和 LinkedIn。作者用一个 JBang 运行的 Java 脚本 SocialPosts.java 实现自动化：在 GitHub Actions 部署前后对比 RSS 源识别新文章，读取页面中的作者与正文，并调用 Claude 为各平台生成文案。Mastodon 和 Bluesky 可直接发布；LinkedIn 公司页缺少可用 API，脚本会把文案和链接发到 Slack，供人工在发布器中补充作者提及。脚本还处理作者提及格式、各平台字数限制、预览图上传和凭证管理；发布失败或缺少凭证时会降级到 Slack 或仅打印内容，不影响部署，并支持 --dry-run 测试。

JetBrains 宣布 Junie Local 在 Mac M5 上的代码生成速度从约 40 tokens/s 提升至约 70 tokens/s，峰值可达 107 tokens/s。此次提升主要来自采用 Splash 推理引擎和新的 DFlash2 草稿模型。官方还针对 Qwen3.8-3.6-27B-blend 微调 DFlash2，以提升编程任务中的接受率；预填充速度由 850 tokens/s 提升至 1200 tokens/s，在 10 万上下文下内存占用约 24GB。新版本开始支持配备 64GB 内存的 M4 Mac 及更新机型，但 M4 上的预填充速度约为 M5 的四分之一。用户可通过 junie update 升级，并在 Junie 中运行 /local 后按 ctrl+r 更新推理引擎。

Kafka按偏移量读取、没有消息索引，故障时难以定位消息卡在哪一环节。作者在黑客松中为Kafdrop加入消息搜索：按时间戳定位起始偏移，分批向前扫描，并设置结果上限和扫描上限以控制内存与Broker负载。实现上使用assign而非subscribe，不提交偏移量，配合只读凭证和Kubernetes小规模部署，获得SRE认可。调试时先按唯一ID搜索消息，再检查下游消费组延迟和消费者日志，可快速区分消息未到达与消费逻辑异常，缩短事故诊断时间。

JetBrains为Junie推出Eco模式，将编程任务拆分为规划与执行两阶段：先由用户选择的高能力模型阅读代码、分析需求并生成结构化计划，再交由低成本模型完成改文件、运行测试和修复等实施工作。内部基准B和A显示，该模式使每项任务平均模型成本分别下降57%和48%，平均解决率变化不足1个百分点。Eco模式仅在需要修改代码时启用，且每个任务只进行一次模型交接，避免反复调用高价模型。该功能已在部分JetBrains IDE测试版及Junie CLI 26.10.20及以上版本提供。

JetBrains 在 IDE 中推出 Air，将编码代理集成到开发环境，方便管理多个代理会话、跟踪进度并审查代码更改。用户可为每个任务选择不同的 AI 代理（如 Codex、Gemini、GitHub Copilot、Claude Agent、Junie），并通过插件或 2026.3 EAP 内置使用。Air 支持在编辑器中打开代理会话标签页，查看差异、运行测试，并将反馈发送回代理。该系列第一部分介绍了基本工作流程，包括设置代理、启动会话和审查结果。Air 不自动安装代理，用户需自行连接并管理数据。

Spring AI 2.1 为 VectorStore 新增 upsert 与基于查询向量的 similaritySearch 重载，允许应用直接传入文档及自定义嵌入向量，而不再调用向量库配置的嵌入模型。该能力适用于已有文本嵌入，以及图片、视频、音频等多模态检索场景。文章以家具目录为例，使用 VertexAiMultimodalEmbeddingModel 生成商品图片向量，通过 upsert 写入商品元数据和图片引用，再用相同模型嵌入搜索文本以查找相似商品；稳定的 SKU 派生 ID 可避免重复。upsert 会新增或替换同 ID 文档，但单次调用不保证事务性。EmbeddedDocument 会校验空向量和非有限值，向量库也会在可获知维度时检查维度匹配。截至 2.1.0-RC1，PGvector、Redis、Elasticsearch、Qdrant 和 OpenSearch 已支持这些能力。

Spring AI 2.1 将消息内容改为有序的 MessagePart 列表，以保留推理模型返回的推理块、工具调用和签名等不透明数据，并按原顺序回放。该抽象支持 OpenAI Responses、Anthropic、Google GenAI、Bedrock、DeepSeek、Mistral、Ollama 等模型，解决此前字符串结构无法保存顺序、加密推理和流式片段的问题。新增 Session 会话记忆会把每条消息的完整部件及工具轮次持久化，使推理在多次调用和服务重启后仍可延续；旧 ChatMemory 被弃用。更新保持向后兼容，但升级后读取推理内容需改用统一接口。

文章在Unikernel Nanos上使用Eclipse Temurin 25复现Akamas的GC研究，通过Renaissance page-rank基准在Oracle Cloud ARM64环境测试Serial、Parallel、G1、ZGC和Shenandoah五种HotSpot垃圾回收器，并验证堆内存释放（uncommit）。结果显示五种回收器均可正常运行；相较G1，Parallel执行时间减少20.7%、峰值堆内存减少38.2%，Serial执行时间减少22.8%、峰值堆内存减少45%；ZGC最大暂停约0.04毫秒但峰值堆内存增加74.6%，Shenandoah暂停约1毫秒。G1在每轮Full GC后可释放未使用堆至约0.5GB，ZGC和Shenandoah在启用uncommit时也能释放内存；当-Xms等于-Xmx时释放被禁用。结论是没有通用最优GC，Nanos上仍可沿用熟悉的JVM调优策略。

文章指出，在AI加速漏洞利用的时代，企业自行维护无商业支持的OpenJDK已难以为继。AI代理可在漏洞披露后数小时内串联多个漏洞入侵系统，而组织修复已知漏洞的中位时间仍达43天。低危漏洞也可能被组合利用，最终获得完整控制权。调查称约20%企业仍在生产环境运行已终止支持的Java 6或7，面临新漏洞与合规、保险审查压力。文章还列出数据泄露成本上升、网络保险费率提高和审计举证负担加重等问题，并介绍Azul Core通过SLA安全补丁、稳定性更新和旧版本回溯支持来转移部分运维与响应负担。