如果你的代码活了三十年还没死，最后被一个陌生人修好了，你会怎么想？

这件事上周发生在了 Roedy Green 身上。不过他已经没法知道了，因为其本人已在 2023 年去世。

但这件事值得大家看一看。

事情起因是一个叫 lexvalo 的开发者想把自己做的 AI 应用 RiverScript 提交到一些老牌的桌面软件目录站。他很快发现了一个早已被遗忘的世界：PAD 文件。

PAD（Portable Application Description）是 1990 年代末出现的一种标准——开发者准备一个 XML 描述文件放在自己网站上，然后提交这个文件的 URL 给各个软件下载站，对方就能自动拉取应用信息。相比现在每个发布平台都要填几十页表单的做法，这个方案简洁得不可思议。

问题在于，唯一能用的批量提交工具是一个 Java 程序。最后一个版本发布于 2017 年。

这个工具的作者就是 Roedy Green。他运营着 Canadian Mind Products 网站，几十年里写了大量免费 Java 工具，维护着在开发者圈子里很有名的 Java Glossary。但他最出名的作品是一篇讽刺文章——《如何编写无法维护的代码》（How To Write Unmaintainable Code），一个程序员圈子里的经典名梗。

所以当 lexvalo 发现自己是这个"传授如何编写不可维护代码的人"写的代码的新维护者时，他在 Reddit 上写了一句话："Roedy，你将近三十年前写的代码，今天被人维护了。"

工具本身倒没坏，功能都在。只是它完全不知道现代 Web 的存在。

三个 bug，修起来不复杂，但每个都精准地卡在 HTTPS 普及之前的世界观上。

第一个：URL 自动纠错逻辑只认 http:// 前缀，遇到 https:// 就拼成 http://https://... 这种地址。

第二个：Java 的 HttpURLConnection 不会自动跟随 HTTP 到 HTTPS 的重定向——当年 HTTP 还是主流，这个行为是默认的。现在几乎所有网站都强制 HTTPS，工具每次都只能拉到重定向 stub 而不是真正的 PAD 文件。

第三个最致命：代码里有一行 System.setProperty("jsse.enableSNIExtension", "false")，在 JVM 层面全局禁用了 SNI。这在当年可能是个合理的 workaround，但现在 CDN 托管的网站全靠 SNI 来返回正确的证书，关掉它意味着每次 HTTPS 握手都直接失败。

lexvalo 把这些修好后，还做了一件事：原来那 66 个提交目录是硬编码在 1500 行的 Java 枚举里的，其中不少网站已经不存在了。他把列表抽到了一个纯文本 sites.txt 文件里，不用重新编译就能改。

代码放在 GitHub 上：lexvalo/mini-pad-submitter-revived。

Reddit 上的反应很有意思。最热门的评论写的是："这就是我们需要的。好故事，讲得好。感谢你没有重新发明轮子，让 Roedy 在'第二次死亡'之前又多活了一会儿。"

"第二次死亡"这个说法来自一个概念——一个人真正的消逝不是肉体死亡，而是世界上最后一个记得他的人也离开了。对于一个把代码留在了世界上三十年的程序员来说，有人在 2026 年修好了他的 Java 1.0 时代的工具，这件事本身就很难用"技术"来概括。

另一个评论说："维护一个已故之人的开源项目，感觉很诗意。"

也有人调侃——既然作者写了《如何编写无法维护的代码》，那他的代码到底好不好维护？答案是：挺好的。讽刺文章归讽刺文章，Roedy Green 作为 Java 开发者的功底没得挑。三十年前的 Java 代码能在三天内被一个陌生人修好重新跑起来，这本身已经证明了实力。

PAD 标准大概不会再复兴了。这个工具也许以后也没人用。但一个程序员为另一个程序员续命这件事，它发生在 2026 年 7 月的一个普通周末——一个人想给自己的应用做推广，结果顺手修好了一段历史。

参考来源：

• Maintaining the code of the man who wrote "How To Write Unmaintainable Code" — r/programming
• Mini PAD Submitter 26.3 Revived — GitHub
• How To Write Unmaintainable Code — GitHub
• Roedy Green's Java Glossary — Canadian Mind Products