每日新聞摘要

Spring MVC's ResponseEntity normally sets HTTP headers automatically, but you should explicitly set the Content-Length header when the response size is known in advance to ensure correct transfers and client compatibility. Content-Length conveys the exact byte count of the response body; omitting it can cause the server to use Transfer-Encoding: chunked, which is appropriate for streaming or dynamically generated content but not for file downloads or clients that track progress. For text responses calculate bytes using the correct character encoding (for example UTF-8). For binary data and file downloads determine the byte size from the byte array or file and set it via contentLength(...) or HttpHeaders.setContentLength(...). Verify resource existence and sizes to avoid client-side errors, and avoid declaring Content-Length for streaming/SSE endpoints. In most REST cases letting Spring manage the header is safest; set it explicitly only when the exact byte count is known and required.

在 Spring MVC 中，ResponseEntity 通常会自动管理 HTTP 标头，但当响应大小已知时，应显式设置 Content-Length，以确保传输准确并与客户端兼容。Content-Length 表示响应主体的精确字节数；省略它可能导致服务器使用 Transfer-Encoding: chunked，这适用于流式或动态生成的内容，但不适用于文件下载或需要显示下载进度的客户端。对于文本响应，应使用正确的字符编码（例如 UTF-8）计算字节长度；对于二进制数据和文件下载，应从字节数组或文件获取大小，并通过 contentLength(...) 或 HttpHeaders.setContentLength(...) 设置。确认资源存在且大小准确以避免客户端错误，通常只有在确知精确字节数且必要时才显式设置，该场景下显式设置可提升兼容性和用户体验。

This article explains the "Public Key Retrieval is not allowed" exception seen when a Java client connects to MySQL 8. The error arises because MySQL 8 uses caching_sha2_password and, when SSL is unavailable, requires an RSA public key to encrypt the password; Connector/J blocks automatic retrieval by default for security. The author reproduces the problem using a two-machine test (MySQL server and Java client), showing a JDBC URL with useSSL=false and allowPublicKeyRetrieval=false triggers the exception. Fixes include a development-only workaround (allowPublicKeyRetrieval=true), the recommended production solution of enabling SSL with a CA-signed server certificate and a Java truststore (sslMode=VERIFY_CA), and as a last resort switching the user to mysql_native_password. The guide details certificate generation, MySQL SSL configuration, and client truststore setup so the secure SSL option removes the error.

本文介绍了在 Java 客户端连接 MySQL 8 时出现“Public Key Retrieval is not allowed”异常的成因与解决方案。问题来自 MySQL 8 的默认认证插件 caching_sha2_password：如果未启用 SSL，密码交换需要用服务器的 RSA 公钥加密，而 Connector/J 为安全起见默认禁止自动检索该公钥。作者以两台机器的测试环境重现该错误，并给出三种处理方式：开发环境可临时在连接字符串中开启 allowPublicKeyRetrieval=true；推荐的生产方案是为 MySQL 配置 SSL（生成 CA 与服务器证书、设置 ssl-ca、ssl-cert、ssl-key）、在 Java 客户端导入 CA 到 truststore 并使用 sslMode=VERIFY_CA；最后还可将用户认证改为 mysql_native_password，但安全性较低。

This tutorial compares strategies for obtaining an element's index when using a LinkedHashSet. It shows that straightforward iteration or converting the set to a List/array performs linear searches and may double memory usage. Using separate List and Set structures preserves order and uniqueness but still yields O(n) index lookups and complicates removals. A custom index-aware implementation that maintains two maps (element→index and index→element) can achieve constant-time add, get and indexOf operations, at the cost of O(n) work when removing elements due to index shifting. The article also presents a complexity table, discusses trade-offs for different operation mixes, and highlights concurrency concerns: compound operations across multiple containers must be performed atomically (e.g., via synchronization) to remain correct. Wrapping behavior in a dedicated class offers the most flexible path for future optimizations.

本文比较了在 LinkedHashSet 中获取元素索引的几种策略。作者指出，直接遍历或转换为 List/数组都会执行线性搜索，并可能导致额外的内存开销；使用 List 与 Set 分别维护顺序与唯一性虽能保留各自优点，但索引查找仍为 O(n)，且删除需额外处理。文中建议使用双映射（元素→索引、索引→元素）的自定义实现，将添加、按索引获取和 indexOf 操作降为常数时间，但删除元素时需移动索引，成本为 O(n)。文章还提供复杂度概览并讨论多线程访问时的一致性和同步问题，最后建议将逻辑封装到专用类中以便未来优化。

This article examines techniques for printing JUnit assertion results to logs to aid debugging, CI/CD monitoring, and reporting. It starts with the simplest approach: include descriptive assertion messages and explicit info logs before and after assertions so successful and failed checks appear in logs. It then demonstrates wrapping assertions in a custom Assertion/AssertionWithMessage API and a LoggingAssertions.assertAll method that logs each assertion's outcome, records errors, and rethrows an AssertionError if any assertion failed to preserve test failure semantics. Finally, it shows implementing a JUnit 5 TestWatcher/BeforeEachCallback extension to log test lifecycle events (before each test, on success, and on failure), which centralizes logging when tests are designed with one assertion per test. The article recommends clear messages as a baseline and building utilities or extensions for more complex needs.

本文概述了在 JUnit 中将断言结果打印到日志的几种方法，以便调试、CI/CD 监控和生成基于日志的报告。首先建议在断言中使用明确的提示信息，并在断言前后添加日志以标示执行流程；然后展示通过自定义 Assertion 与 AssertionWithMessage，以及 LoggingAssertions.assertAll 对断言逐一执行、记录通过或失败并在存在失败时重新抛出 AssertionError 的方案；最后介绍实现 TestWatcher 与 BeforeEachCallback 的 JUnit 5 扩展，用于在测试开始、成功或失败时集中记录日志。文章建议以清晰的断言消息为基础，并在需要时构建工具或扩展以处理更复杂的断言逻辑。

This short Medium post by Sam Cooper, titled "What does ‘throw return’ do in Kotlin?", is presented as Puzzle 16 of 23 in a Kotlin Brain Teasers series and carries the label "The Vacuous Boomerang!". The excerpt functions as a compact brain teaser prompt that raises the question of how the 'throw return' construct behaves in Kotlin. Rather than providing a full explanation in the snippet, the entry directs readers to continue reading on Medium to view the complete puzzle statement and any accompanying discussion or answers. The piece is positioned as one of a sequence of bite-sized challenges intended to prompt thought about Kotlin language behavior, with the full content available via the linked Medium article.

这篇由 Sam Cooper 在 Medium 发布的短文，题为“在 Kotlin 中‘throw return’ 是做什么的？”，为 Kotlin Brain Teasers 系列的第 16 题（共 23 题），并以“The Vacuous Boomerang!”为题。摘录以简短的脑筋急转弯形式提出问题，指向 Kotlin 中 'throw return' 的行为，但片段本身没有给出完整解释或答案，而是引导读者继续在 Medium 上查看完整的题目内容和相关讨论。该文章作为一系列简短题目之一，旨在激发对 Kotlin 语言行为的思考。

In this article the author challenges the common developer rationalization “I’ll fix it later,” opening with a familiar scene: it’s late, a feature must ship tomorrow, and you hastily code a compromise. The piece argues that treating future time as a guarantee is a myth that allows recurring shortcuts, creates technical debt, and degrades product quality. Rather than accepting the pattern as inevitable, the author highlights the real costs of deferral and emphasizes accountability for addressing issues promptly. The title’s parenthetical promise—“And How to Kill It”—signals that the article moves beyond diagnosis to present practical approaches for eliminating the reflex to postpone fixes, helping practitioners avoid repeated last‑minute compromises and ship more sustainable, higher‑quality code.

作者以常见情境切入：为赶明天上线的功能，深夜妥协写出需要“以后再修”的代码，指出这种自我安慰是个误区。文章论述将问题留给未来只会导致反复的权衡、累积技术债并影响产品质量，而所谓的“以后”并不能自动修补当前的妥协。除了说明拖延带来的代价外，作者也在标题暗示下提供了可行的做法，旨在帮助开发者摆脱“以后再修”的惯性，减少临时折衷，以更可持续、更高质量的方式交付代码。