为了应对新工作，笔者在过去两周一直在重新熟悉一位老朋友：JAVA。我以JAVA开启了我的软件事业，与之共行了两年半左右的时间。但是随着容器和微服务的出现，JAVA很快消失了。时至今日，距我上次用Java正经写代码已有三年。笔者没想到它会再次出现，尤其是出现在微服务领域。
这是怎么回事?答案很简单：无处不在的微服务铺天盖地。
- 易于扩展
- 高可用性
- 更简单的代码库，不必担心并发和多线程
- 容器化带来的便携性
所有这些都使人们质疑Java(更具体地说是JVM)，更不用提Java最臭名昭著的Spring框架了。
有时，人们沉浸在Kubernetes之类的技术中，感觉Java的时代已是历史，Java在容器和微服务生态系统中表现欠佳(软件可扩展性和高可用性的关键)。尽管被Python等语言(笔者现在的首选语言)的简单和优雅所动摇，但作为Java曾经的死忠粉，笔者认为Java仍在某些领域有毋庸置疑的优势。
例如，Java有强大的线程功能，笔者职业生涯的早期就将它们直接用于关键银行应用。虽然将编译语言与脚本语言的性能指标进行比较并不公平，但Java坚如磐石的性能确实无与伦比。
而对于水平扩展性和微服务体系结构，这种语言固有性能的作用微乎其微，因为人们可以直接产生更多容器来获得出色的性能。显然，这些脚本语言，再加上在容器范围内即时放大或缩小的能力，就能使Java打道回府了。笔者确信，Java已死，至少在微服务领域。
在新工作中，笔者进一步确信并痛苦地意识到这种语言有多令人厌恶、烦躁和费解(一部分在于Spring等过时的死板框架)。
Java与Spring的一派正经
首先讲讲臭名昭著的Spring框架。与五年前无异，Spring体积庞大且令人费解，充斥着无穷无尽的注释，开发人员每次要么得求助于教程或示例代码，要么只能研读Spring提供的冗长文档。
Spring本就采用了一种很死板的语言，用单行注释和看似简化的包装器加以掩盖，从而加剧了这个问题的严重性，这些包装器会带来一堆调用和类别例示，通常都派不上用场。
所有开发人员都同意这点：语言的可控性、指令和透明度对是高效开发软件的关键。简而言之，开发人员希望准确了解代码中发生了什么以及执行了哪些例程(至少是在较高层次上)。但Spring在此有着极大阻碍。
如果必须在类的顶部插入六个各自运行任务注释，它们在Spring环境中错综复杂地相互联系，那你的处境就复杂了。不仅Spring如此，以Lombok库为例。这是其首页上第一行描述：
“Lombok项目是一个Java库，它会自动插入您的编辑器和构建工具中，从而为您的Java增光添彩。无需再编写另一个getter或equals方法，一个带有注释的类将具有功能全面的生成器，自动执行日志记录变量等等。”
压缩Java代码的目标不过是照本宣科，不能真正发挥作用。
Java应该停止匹配脚本语言的简洁性。第一，这牺牲了Java代码的一致性：想象返回Java发现所有的getter和setter都消失了，取而代之的是单行注释@NoArgsConstructor。这哪还有一致性?
其次，它增加了本就费解的抽象数组。例如，Spring可以在后台设置自动装配(bean注入)，这是可以理解的，但是Lombok在应用程序环境中位于何处，以及如何协调消息?如果每个类都有六个注释，那么这些注释还实例化了多少其他例程或类来完成这种简单的工作?
每个开发人员都不希望有额外的代码四处潜伏。然而这就是笔者三年后遇到的Java代码，没有任何改变。实际上，微小的变化也只会使情况变得更糟。Java仍然侧重于愚蠢的规则，这些规则规定了应使用的类名，所在的包，以及变量是私有的还是受保护的。但根本没人在乎这些。
相比之下，Python对缺少语言的访问说明符直接回复：“大家都是成年人了”。这仅仅一行的回复嘲讽意味十足又极具吸引力，它立刻引起了我的共鸣，我过去常常觉得荒谬且无用的概念在它的影响下合理了很多。
保持简单，程序员们
在软件行业，你经常能听到人们说“KISS”：保持简单(Keep it simple)，傻子们(Stupid)。Java只有认真考虑这点才能生存。
如今，微服务模式在软件行业中几乎无处不在，甚至许多运行古早应用程序的组织也越来越多地替换其旧的整体，以简化设计并提高可扩展性。对于程序员而言，这意味着将其庞大的代码库或复杂的业务逻辑分解为更简单、简洁的功能——一种无需在代码中进行状态管理的范例，从而避免并发和多线程的问题。
归根结底，无论何种服务，都只处理某种格式(JSON或XML)的数据，然后将它们传递到消息总线(如Kafka)以进行进一步处理。即使是这样简单的设置中，Java和Spring还在照搬过时又死板的代码语法：Application Contexts、 bean injections,、autowiring、 POJO mappers、需要大量内存的 JVM、讨厌的 class loader。
所以，结论是什么?“保持简单，程序员们!”
