[draft] new

[draft] add inside java episode link

2 files changed, 45 insertions, 0 deletions

diff --git a/content/en/article/generated-code-policy.md b/content/en/article/generated-code-policy.md
new file mode 100644
index 00000000..3f4fd9ff
--- /dev/null
+++ b/content/en/article/generated-code-policy.md
@@ -0,0 +1,23 @@
++++
+title = 'Generated Code Policy for my projects'
+subtitle = ''
+slug = ''
+tags = []
+categories = ''
+date = 2026-09-02T13:28:39+08:00
+draft = true
+toc = true
++++
+
+I've been looking closely at some of my Mac apps, and I noticed how [SuperCMD](https://github.com/SuperCmdLabs/SuperCmd) haven't fixed their homebrew cask issue even though somemone created a [Pull Request](https://github.com/SuperCmdLabs/homebrew-supercmd/pull/3) months ago. Warnings pop up everytime I run `brew update` and it annoys me. I looked through the repository, and could not help but notice how much *contribution* Claude had made and that they lack an LLM policy. Well, I'd rather not have TypeScript written by Claude running on my laptop. 
+
+The alternative I found is [vicinae](https://github.com/vicinaehq/vicinae). For a QT project, it looks pretty good. In `CONTRIBUTING.md`, they said:
+
+> AI generated code is treated the same as regular code. As such, all the aforementioned rules apply.
+>
+> AI is not a substitute for properly understanding and testing your code: don't be lazy. Lazy AI PRs that do not respect the guidelines will be rejected. In particular, keep your pull request's description as concise as possible: no maintainer will read your novel.
+>
+> If your contribution was mostly AI generated, it's considered good practice to indicate what model or tool you used for that.
+
+It seems to tolerate heavy use of LLM with some mild restrictions, but fair enough. 
+
diff --git a/content/weekly/97.md b/content/weekly/97.md
index b6ab7457..f4d8d8a4 100644
--- a/content/weekly/97.md
+++ b/content/weekly/97.md
@@ -37,6 +37,25 @@ fedi = ''
 
 ## 鸡头蛇尾
 
+### Java 其实是“内存高效”的
+
+> 📻
+> [Inside Java: “Java *is* Memory Efficient”](https://inside.java/2026/05/28/podcast-059/)
+
+Java 一直给人消耗很多内存的印象，事实也的确如此，不过 Oracle 的 Java 架构师表示：*It's not a bug. It's a feature.*
+
+简单来说，Java 的垃圾回收机制选择消耗更多的内存，以换取更少的 CPU 周期[^1]。即便是在内存价格暴涨的今天，CPU 的成本也比 RAM 高，所以多用 RAM 以减少 CPU 时间无可厚非。再者，假设某个程序占用了 100% 的 CPU 时间，那还不如也占满 100% 的 RAM，因为此时已经没有其他能够取得 CPU 时间片的程序去用剩余的内存了。
+
+不过 Java 是怎么做到用 RAM 换取更少的 CPU 周期的？逻辑上似乎说不通，从算法的角度考虑，选择更好的数据结构的确能减少时间复杂度，但从编程语言的机制来看，很难理解占用更多的 RAM 是怎么减少机器指令的数量的。
+
+Ron Pressler 是这么解释的：想象内存无限的机器，有一个 C 程序固定调用很多 `malloc()` 和 `free()` 函数来分配和释放内存，内存管理所需要的步骤是确定的；另一个 Java 程序得益于 Java 的内存机制，**永远不会回收内存**，因为 Java 的垃圾回收只会在限定的堆大小快被占满的时候释放内存，所以 CPU 时间就减少了。
+
+合理，但是我有点无语。
+
+此外，他们还顺带反驳了「Java 很慢」的这个观点。我同意他们说的「基准测试是不准的，除非专门为自己的程序定制测试方法」这个观点，但这并没有说服「我 Java 不慢，慢是算法问题」。在各种不同类型的[基准测试](https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html)中，Java 都不能排在前面，更何况 JVM 启动耗时也是消除不了的瓶颈。
+
+不过这期播客也让我意识到，Java 如果只用来写较大型的 Web 后端，的确不用为内存操心，人们对 Java 内存占用极高的印象往往来自与内存本身就比较受限的场景，比如桌面应用和在配置较差的小 VPS 上部署的应用。用对了地方兴许是好的，但这不妨碍我继续认为 Java 是一门很丑的语言，语法（syntax）和语义（semantics）都很丑。
+
 ### Linux 内核也难逃 “AI” 爬虫毒手
 
 > 📜
@@ -76,3 +95,6 @@ fedi = ''
 
 ## 漫步遐思
 
+## Footnotes
+
+[^1]: 原文是 *CPU cycles*，应该是指 *Instruction cycles*，即指令周期，CPU 完成一条机器指令所需要的时间。