2024年Stack Overflow调研显示，Java仍占据企业后端开发35%的份额——这个数字和十年前几乎没变。可打开技术社区，你看到的是另一幅画面：新手教程里它被当成"legacy语言"一笔带过，面试题里"如何避免Java代码臃肿"成了必考点。
问题从来不是Java没用了。是大多数人评价编程语言的标准，和严肃软件要解决的实际问题，早就脱节了。
那场永远在重复的辩论
某个开发者用Java写了基础课作业，或者抄了几段冗长的示例代码，再拿它和为快速原型优化的脚本语言对比——结论总是雷同：过时、啰嗦、太"企业级"。像是被迫使用，而非主动选择。
这个判断在三个前提下成立：追求语法新鲜感、迷恋极简符号、只关心单个文件里的编码快感。
前提一变，结论就崩。
银行不会告诉你的事
全球前50大银行的核心交易系统，超过80%基于Java构建。不是因为他们怀旧，是因为当每秒要处理12万笔并发交易、且不允许丢一条数据时，"啰嗦"的显式类型声明和严格的编译期检查，从负担变成了保险。
作者Rupan Prasai打了个比方：用脚本语言快速搭个Demo，像用胶带和硬纸板做飞机模型；而Java的设计哲学，是假设你最终要造一架真的能飞的客机。胶带在风洞里会融化，硬纸板扛不住气压差——这些在桌面演示时根本看不见。
真正的问题从来不是语法行数，是故障发生时你能不能定位到具体哪一行。
"正确"使用Java的隐藏条件
Prasai的核心观点是：Java的口碑崩塌，源于大量使用者根本没按它的设计意图来。Spring Boot让启动项目变得太容易，结果一堆人把本该拆成微服务的单体应用硬塞进去；Stream API被用来写一行式"聪明代码"，可读性反而比传统循环更差。
语言给了工具，使用者选了最省力的那把，然后抱怨工具太重。
这有点像抱怨单反相机不如手机拍照快——如果你只发社交媒体，确实如此。但当你需要打印两米宽的户外广告时，手机的那点像素会暴露一切。
一个被忽略的时间线
Java近年的更新节奏在加快：每六个月一个特性版本，模式匹配、虚拟线程、值类型逐一落地。Project Loom让高并发编程的代码复杂度大幅下降，而保持类型安全这个底线不动。
换句话说，它正在吸收其他语言的优点，同时拒绝放弃自己安身立命的东西。
社区里有个老梗：Java程序员35岁不会失业，因为维护那些跑了二十年的系统需要人——而且得是能读懂当年设计意图的人。这个梗讽刺了两件事：一是Java系统的长寿，二是行业对"能长期运转"这件事的复杂情绪。
Prasai在文末留了句话：「选择语言时，先想清楚你要解决的问题是会存在六个月，还是十六年。」
你的项目打算活多久？
热门跟贴