为什么我不再担忧，并学会热爱治理和品牌的变化。

开发者们对于他们用于开发的工具和语言可能充满热情。这种热情是一把双刃剑。它可以促进技术的普及和激发能量投入到人们选择倡导的语言的方向中。这种热情也可能吓跑那些希望使用该语言或刚进入该领域的人，特别是当相反的观点被夸大、不正确或与当前技术状态脱节时。后一种情况（通常是无意地）在关于相关技术的对话中注入了恐惧、不确定性和疑虑 (FUD)。

Java 回顾

Java 在 20 世纪 90 年代中期被引入。多年来，该技术固有的问题以及该技术的治理问题一直层出不穷。提出的许多问题都是有效且重要的。其他的则不然。曾经存在关于速度、浮点运算、无符号数处理等等的问题。随着语言的成熟，大多数技术问题都已得到解决。Java 回顾涵盖了基础语言、支持该语言的工具（JVM）、其许可和总体品牌管理。此外，Oracle 和 Google 之间引人注目的法律纠纷持续了多年，无疑为合理和夸大的 FUD 打开了大门。

上述许多性能和安全问题已由软件工程师在维护和完整修订的开发版本中得到解决。事实上，该语言在不断发展，即使平台版本 8 似乎已步入正轨，版本 9 也已于去年 9 月全面上市，并且依赖于该语言和工具的开发者社区似乎也通过轶事证据表明，他们已经深入到实验和采用阶段。版本 9 仍然是一个相当新鲜和最新的版本，版本 10 已经达到了候选发布阶段。一些 Java 问题已随着治理模型的演变、法律问题的解决和许可问题的澄清而得到解决。曾经有一段时间，各种项目似乎可能导致分裂：IcedTea、Harmony 等等。然而，这些积极支持和 backing OpenJDK 项目的大公司，将他们的辅助工作、工程师和品牌声望带入其中，值得称赞他们在近年来加速和推进 Java SE 方面所做的贡献。

近期动态

Java 企业版是近期一个备受关注的领域，充满了讨论，是的，也是 FUD 产生的源头。那么，到底是怎么回事呢？

简而言之，Oracle 推出了企业版的控制权——对于非 Java 开发者和此处的讨论目的而言，企业版可以被认为是 Java 工具箱中所有“重型”级别的工具，这些工具不是由基础语言、JVM 和 JDK 提供的。或者，换句话说，EE 为我们这些凡人和过于繁忙的开发者提供了各种工具、框架和其他有用的工具，以抽象出构建企业级软件例行程序的大量苦差事。

Oracle 在此标准和代码库治理方面的举动是一个巨大的转变。

“Java 方式”，包括标准版和企业版

对于我们大多数 Java 人来说，我们不会花费大量时间思考内存管理。编程的这个关键方面消失了吗？没有。但是，JVM 提供的工具简单地处理了大量的样板代码和例行任务。这个包罗万象的“Java 工具箱”正在为我们处理大部分甚至全部的内存管理业务。

我记得当我编写我的第一个 Java 程序时，我声明并初始化了变量，但没有回过头来清理自己并回收内存，这让我感到有点不安。但是，嘿，JVM 正在处理它，并且多年来，它在回收程序不再需要的资源方面变得更加高效。处理内存几乎完全被抽象化了。当时那种奇怪的失落感现在看来几乎是侵入性的，当它出现在一个项目中时：“嘿，我为什么要考虑这个？好吧，我将做一些 JVM 调优或稍微优化一些代码。”

在许多方面，这种抽象化仍在继续——有时比我意识到的还要快。一些方法被坚持下来，并被纳入 Java SE/EE 标准的某些层。另一些则失宠了。还有一些非常出色且使用起来令人愉悦的库（比如 JODA time—JSR-310）似乎长期以来被忽视了。Java SE，以及更大程度上的 Java EE，在很大程度上反映了这种持续的演变。进化树有很多分支。

最终，大多数包含的层都是有益的。开发例行程序以拼接来自多个供应商的各种数据库的数据是一项典型的编程任务——只是普通的集成和报告。早期，能够通过 JDBC 连接使用现有的 ODBC 是很棒的！不久之后，JDBC 就发展起来了，曾经需要的 ODBC 层被丢弃了，对于标准来说是不必要的。这并不是一蹴而就的，但它发生了。最终，很明显，Java 开发者仍然在编写相当多的自定义或原生 SQL 来获取我们需要的数据，并且仍然在处理跨数据库产品的差异。

瞧，JPA——又一个 JDBC 之上的抽象层——出现了。现在，在许多方面，大多数数据库交互都是通过 Java 对象和实体管理器的视角来进行的，以处理 Java 和各种数据存储（如 PostgreSQL 或 MS-SQL，甚至是 NoSQL 数据库，如 Mongo）之间的数据翻转。EE JPA 工具处理了供应商实现之间的许多特性。通常，人们只需要让 EE 工具（体现在容器中）知道我需要与之通信的 RDMS 的“风格”甚至版本。正如前面 Java 和内存管理的例子一样，这并不是说我在处理数据库时不会考虑优化或提高性能——当我需要时，或者我可以绕过某个特定用例的层——但是很多繁琐的工作只是交给了提供的工具。我在需要的地方介入。而且，在我在运行时进行工程设计的情况下（我承认这太频繁了），我只是添加一个优化循环（通常在代码审查中）来提高我希望拥有的速度，或者将优化积压到未来的点发布中。

Java EE 的缺点

好吧，您有许多层和框架可供选择，因此您必须做出决定。过去，我有时会使用触发器或存储过程来解决数据库问题。今天在某些情况下我仍然可能会这样做。但是，在做出选择之前，我会问自己类似“值得吗？”、“提供的工具或抽象能否完成工作？”以及当然非常重要的“与可能不会被注意到的性能提升相比，留在容器中是否会让跟随我的程序员甚至当前的队友更容易，如果我在 Java 提供的（标准版或企业版）工具之外进行优化？”

当然，与任何成熟的语言一样，有一个完整的项目生态系统可以填补尚未被标准吸收的空白。

Java EE 的优势

如果这些扩展的特定实现变得不稳定——也就是说 FUD 进入了画面——那么就拿起你的代码并跳转到不同的容器。为什么？因为 Sun Microsystems（被 Oracle 收购）意识到它抓住了一只老虎的尾巴，并且需要某种治理模型来使这个 Java 创造物保持在正轨上。这个模型总是好的或顺利的吗？不。但是，它是否提供了一种让人们参与进来的方式？是的。

从宏观的角度来看，这是一个不错的选择。它可以做出更大的选择吗？例如，将 Java 推向 ISO 组织或 IEEE 组织？也许。但是，为什么要争论假设，对吧？重点是有一个论坛。宏观来看，撇开治理方法的缺点、磕磕碰碰和挫折，Java 开发者可以依赖的“工具”（包括 JVM 标准/基础层和企业/扩展层）现在都具有相当好的可预测性。如果一个 EE 产品——甚至给定的 EE 产品或容器中的特定层——变得不稳定，只需跳转到其他 20 个符合这个非常有能力的最低共同标准的产品之一即可。

当 Oracle 开始暗示它准备为 EE 寻找新的家时，参考实现 Glassfish 似乎岌岌可危。什么样的危险？我们这些针对参考实现进行编码的人可能无法获得商业支持，如果我们需要的话！许多开发者不知道风会往哪个方向吹，不确定性开始出现，这让我产生了一种恐惧感，因为当我们期望求助的供应商在我们遇到某种麻烦时似乎但又不明确地放弃了它所监督的标准代码库，这引入了怀疑。这是 FUD 三连击，不需要意见领袖的帮助。

我依赖 Glassfish。我不知道下一步该怎么办。那是真正可怕的六分钟！（这六分钟包括重新装满我的咖啡杯。）

我用 Google 搜索了 Glassfish 的替代品。JBoss 是我点击的第一个商业链接。Wildfly 是我多年未重新访问的上游开源且兼容的基础。哈扎！我找到了一条出路，并没有陷入困境。如果我向下滚动页面半英寸，我可能会最终尝试 Paraya。

总结

在一个以 EE 为核心的解耦多语言编程世界中，开发者不会被逻辑例程代码锁定。宝贵的编码时间得到了保护。有很多开源选项，因此无论大小的开发商店都可以低成本地配备工具并进行开发。有很多商业和云替代方案，因此生产启动压力得以减轻。此外，EE 容器级别使人们可以尝试不同的外部产品（存储、数据库、每月 SAAS、Web），并以不同的性价比快速进行尝试，因为这主要是一个配置容器以指向这些服务并回到编码业务的问题——所有这些都是开源的普遍优势，但来自标准化治理堆栈的额外安全感。

像 Java SE/EE 提供的受治理的标准化核心堆栈并不会阻止人们拼接某种多语言解决方案。因此，是的，人们可以尝试本周最流行的编程时尚或营销术语，并且如果需要，可以回退或建立在标准流程中证明的技术集之上。

臃肿还是丰富？

尽管如此，Java 还是让开发者变得娇生惯养。我经常而且越来越频繁地发现自己正在寻找一个层，想知道何时该层或其竞争对手成为通过 JCP 体现在 JSR 中的参考实现。为什么还没有区块链的通用抽象？为什么 JSR 中还没有用于与 AI/机器学习通信的通用子系统？统一安全！它已经存在并且正在发展，但是谁的实现将赢得梦寐以求的（我假设的）“参考实现”地位？我在系统之间移动和处理大量数据。等一下。为什么不直接将 Camel 设为正式的 JSR？Wildfly 的人们已经在他们的容器中提供了一个“模块”。

等等。那不是臃肿吗？这不是臃肿。这是一种令人尴尬的丰富。这是开发者可以忍受的问题。此外，人们不必使用 EE 容器。如果您需要 EE 中的某些层/抽象，只需坚持使用 SE 基础并拉入您需要的层即可。例如，假设您需要快速编写一个例程来从多个来源（如上所述）提取数据，并且可能永远不会再次使用这个一次性实用程序。获取 JPA 层并完成即可。扩展和层只是工具。仅仅因为您拥有这些工具，并不意味着开发者必须使用它们。但是，天哪，当您试图完成某件事时，很高兴知道它们是可用的。这些工具？只需让容器为您管理它们即可。顺便说一句，大多数容器以“延迟”方式加载这些层/抽象/工具，这意味着它们在磁盘上，但不消耗 CPU、内存或 I/O，直到您明确需要标准的特定部分。如今磁盘空间很便宜。尽管如此，如果它困扰您，请尝试 Microprofile。

至于上面的愿望清单？既然 Java EE 已经走出了 Oracle，我预计在治理尘埃落定之后，这些企业级工具将开始加速发展，就像标准级语言和工具已经加速发展一样。当然这只是一个猜测，但我敢断言这是一个相当安全的猜测。

当前状态

自从去年夏天那可怕的六分钟以来，事情的当前状态如何？

已经发生了很多事情。Oracle 为 Java EE 的代码库找到了一个家，就在优秀的 Eclipse 基金会。Eclipse 基金会也是一个非常好的 IDE、上面讨论的 JPA 层的实现以及许多其他优秀项目的所在地。许多大公司已经加入了 Eclipse，并将其作为 EE 的管理者。例如，Oracle 仍然加入，Red Hat 和 IBM 也在那里。

到目前为止，他们似乎对像我这样的小人物的担忧持开放态度，我们通常更专注于我们的键盘和屏幕。当事情看起来最不确定时，开发者社区组成了 Java EE Guardians。当我读到 Reza Rahman 的一篇文章时，这个团体首先引起了我的注意。Reza 和该团体虽然担心转型，但因保持冷静并努力与 Eclipse 基金会和 Oracle 进行有节制的对话而赢得了赞誉。Eclipse 基金会因积极倾听并将品牌推广等非工程项目提上议程而获得了肯定。Oracle 虽然允许捐赠的项目保留 Java 名称和 javax 的包前缀会更好，但也因其在这些项目上的直接立场而获得了一些赞扬。它可以拖延流程并含糊其辞，但它没有这样做。嘿，Apache 的各位！感谢您为 Jakarta 名称的使用扫清了道路。许多伟大的项目都在 Apache 的保护下发展起来。

Jakarta 作为新品牌，让人感觉像是一个无缝过渡，尽管其中有很多利益相关者和许多活动部件。

用现代企业术语来说：伟大的情商人士！

Java 依然充满活力，并且发展良好。OpenJDK 不仅似乎继续确保 Java SE 的可行性，而且还给人留下了 Java 核心和生态系统正在加速发展的印象。

Java EE 现在是 Jakarta EE。换汤不换药？如果 OpenJDK 是 Eclipse 上 Jakarta EE（在一个名为 EE4J 的保护伞项目下）的模式，我们应该预料到 Jakarta EE 标准很快将在其新家站稳脚跟，并将作为一个标准加速发展和演变。

放轻松。让对标准版和企业版 Java 未来的恐惧、不确定性和疑虑消散吧。

欢迎，Jakarta EE！