“ Java的未来是什么？” 这个问题经常出现，每当出现这个问题时，博客圈就会激怒，每个人都投入两分钱。 业余爱好者和专家都参与了永无休止的辩论，这些辩论经常在切线上消失而无济于事。 答案（如果确实存在）会因信息过多和冲突情绪的阴霾而迷失。
我对提出的问题没有任何疑问，因为它当然是合法的，即使不是很重要。 实际上，应该认真考虑一下，无论您是对Java投入大量资金的老手，还是试图弄清楚什么是有价值的菜鸟，还是只是自称是Java的仇恨者。
多年来，我抵制了写这个问题的冲动，以实现其非平凡的性质。 最近，在我的另一场Java演讲之后，我发现自己再次参与了漫长的讨论。 直到那时，我才意识到我有足够的勇气写这篇文章。 与其说是参加辩论，不如说是谦卑地分享我的想法和我个人为使自己清晰而付出的努力。 我所保证的只是我偏颇的印象以及对Java花费了数年的固执己见的记忆。 然后由您自己决定要怎么做。
Java深夜脱口秀
在“ Java深夜脱口秀”之后，不需要花费很多时间就可以知道专家通常以解决问题的方式分为两个主要阵营。
第一个阵营是“笨蛋”，他们倾向于在99-bottles-beer.net [1]上枚举每种编程语言的功能，并花时间讨论哪些Java缺少以及需要哪些Java。 。 根据当前的时尚和个人的信念，您最终会听到不同意见，无论是好是坏。 要么是Java的世界末日临近，要么是Java的未来像太阳一样灿烂（没有双关语）。 对于悲观的“ egghead”，2012年是每当某个功能没有进入预期的下一个版本，或者在当前版本中发现新漏洞时，都会发生2012年。
第二阵营由“浪漫主义者”组成，他们继续引用TIOBE索引[2]，证明Java毕竟仍然是最受欢迎的编程语言，并且由于周围的社区而将如此。
双方都提出了比这复杂得多的论据，有些论点如此明确，以至于我发现自己倾向于某一方面。 我不能忽略的事实是，两个阵营处理问题的方式从根本上都是错误的。
反对“笨蛋”的理由是，您只能发展那么多语言。 有些功能根本无法实现，而有些功能与推动该语言最初设计的理念不一致。 这是假设确实需要提议的更改，并且可以说是在正确的方向上进行。 现实情况是，技术不必成为保持相关性的“最热门”。 它可以承受变化的风潮。 它只需要“足够热”，并且我的意思是说它支持在某个时间点满足一般用例需求的一组功能。
相反，“最热门”并不总是足以使一项技术获得广泛采用。 仅当某种事物“非常热”以至于使现状成为“不热”时，范式才会转移其偏爱。 用外行的话来说，人们会一直待在外面，直到他们被娱乐为止，或者直到帷幕落下。
至于Java，它肯定“足够热”。 在破坏性“热点”的临界点附近，我还没有看到足够严重的东西。 尽管有Java早就应该发布的功能愿望清单和一系列令人失望的版本，但这些版本仍在发布。 许多新的开放源代码项目和众多主要软件商店仍在选择它作为事实，这充分表明Java并没有失去其专长。
尽管我不喜欢肆无忌disc地羞辱任何人，但我建议您在浪费时间之前，请三思而后行，看看那些带有“ Java Dead？”等大胆标题的“小报”博客。 或“ The Java Postmortem”。 很有可能出现了一些新技术，并Swift使自己成为一群激动的粉丝男孩。
“浪漫主义者”的表现不会更好。 因为一项技术已被广泛采用并获得了广泛的支持，所以它能够保持成功的想法是一个非常肤浅的想法。 技术的可行性与其社区的健康之间的相关性并不意味着一种会导致另一种。 另一方面，一个健康的社区仅反映了当前的成功，而对未来没有多说。 要衡量当前的成功，当然可以将社区的当前状态作为指标，但是他或她不能在此基础上对未来进行任何预测。
就Java而言，毫无疑问，围绕它的社区是健康的。 从我自己作为JUG（Java用户组）负责人的个人经验来看，它确实是独一无二的。 它是相当大的，高度多样化的，并且绝不是被动的。 Java社区成员不仅是该技术的热情和热情的用户，而且还高度参与了该技术的发展和演进。 对OpenJDK的贡献和Adopt-a-JSR项目的成功证明了这一点。
漫长的“傻瓜式”和“浪漫式”抨击的目的不是要描绘出不切实际的严峻局面，也不是要表明争议是两极分化的，以至于没有足够的空间容纳第三批更合理的人群。 相反，沉默的多数来自两个阵营。 它落在建立“灰色地带”论证之间的某个地方。 这种立场承认双方提出的所有想法的优点，并以一种或另一种方式调和了两种观点。
我把这个问题搁置了很长时间，避免认真思考。 我猜想，加入围墙的人们会更容易。 有一天，我和哥哥一起从事一个项目，他建议使用Ruby代替Java。 讨论进行了一段时间，涉及了一些严重的问题。 由此产生的结果是，人们意识到技术的未来既不是由技术本身决定的，也不是由其周围的社区决定的。 例如，Java本身和Java社区都无法决定Java的未来。 但是谁或什么决定呢？
优胜劣汰
在迷恋了这一点之后，我最终以某种方式最终想将进化的生物学概念应用于编程语言。 “编程语言达尔文主义”的想法对我很有吸引力，并且完全有意义。 在进化生物学中，物种通过自然选择的过程进化。 具有某些特征的个体生物相对于其环境而言是最适合或最不适合的； 因此，最有可能壮成长或最有可能死亡。 换句话说，正是环境决定了对有利特性和对不利特性的偏见，从而决定了物种的命运。
将其投影到包括Java在内的编程语言中，决定它们未来的正是使用它们的环境。
这引起了另一个问题。 在编程语言的上下文中，“环境”到底意味着什么？ 答案令人惊讶地是一个简单的答案。 它将是运行它的硬件，以及它用来解决问题的性质。 例如，Java的成功必须归功于其解决当前硬件问题的能力。 只有合理的假设是，只要“环境”保持不变，Java将继续成为一如既往的成功语言。
范式转变
十年前，执行二进制文件的目标硬件是软件从业人员最不关心的问题，除非它们当然恰好位于嵌入式领域。 Java的人们也同样会少关心。 他们甚至不必知道要编译的目标体系结构。 得益于JVM真正实现了随处写一次运行的承诺。 在另一方面，摩尔定律被证明是非常准确的。 随着机器呈指数级增长，该软件自动实现了性能提升。 换句话说，代码可以在更快的硬件上更快地运行。 生活是美好的，但是没有什么是永远的。
正如物理学家所预言的那样，摩尔定律是无法维持的。 热力学和量子力学定律所施加的热量和泄漏限制只是限制了我们可以在一个硅芯片上容纳多少计算能力。 这标志着时代的终结，因为我们开始构建具有多个内核的计算机。
如果不是彻底的话，硬件的改变是非常重要的。 要了解这对软件世界意味着什么，我们必须首先花一些时间来思考命令式编程范例。 对于包括Java在内的最流行的编程语言所采用的开发人员，这种模型是最熟悉的。
在命令式范式中，计算指令表示为具有变异状态副作用的语句序列。 尽管是最直观的，但是它给开发人员带来了巨大的挑战，因为这给开发人员增加了管理状态的负担。 这个问题只有在并行性发挥作用时才会变得更加棘手。 要求状态更改和访问在并发执行的线程之间同步。 作为开发人员，我们一直在依靠抽象（库和框架）或将不变性纳入我们的设计中来解决这一令人头疼的问题。 在新的多核硬件上，不仅需要跨线程管理状态，还需要跨内核管理状态。
即使不是人类不可能做到的，这也是一场噩梦。 因此，我们最终编写的代码无法利用硬件的全部计算能力，并且受到硅芯片可以支持的最大时钟速率的限制。 这只能意味着一件事。 范式正在转变，地毯已从命令式编程语言中撤出。 Java也不例外！
功能回归
在寻求替代方案的过程中，我们发现自己逃脱了命令状态管理的深渊，陷入了功能范式的鸿沟，在该范式中，没有要管理的状态。 主流中引入了许多新语言，经过数十年的积尘，我们从学术界中复活了其中的一些新语言。 我们正式回归复古了。
那么，Java将会发生什么？ 在我们进行进一步的介绍之前，请允许我在Java“语言”和Java“平台”之间进行重要区分，因为在过去的几年中，两者都在朝着各自的命运独立发展。
我相信，Java“语言”与其他所有命令式语言一起成为另一种COBOL [3]只是时间问题。 毫无疑问，它们都将以它们之前的方式逐步淘汰，成为化石，供语言考古学家研究[4]。 这将花费很长时间，并且考虑到我们已投资多少，将是一个渐进的过程。
向这些语言添加功能特性的热烈竞争是绝望的。 这就像在猪上涂口红。 正如我在文章开头提到的那样，我们只能开发这么多语言。 范式的转变是如此激进，以至于像Java这样的语言根本无法设法朝这个方向重塑自己，而仍被称为Java。 它将一起成为另一种语言。 此外，我想不出什么比假装在Java中具有所有功能都更痛苦的了，它的命令式内存模型对您不利。 如果您喜欢把头撞在墙上，穿铁环做最琐碎的事情，请成为我的客人。
我在这里不建议在Java中添加lambda（例如JSR 335）是错误的。 相反，我认为这是很长时间以来Java发生的最好的事情。 我只是想指出的是，我们应该小心不要被迷住，并喜欢C ++，将其变成a肿的弗兰肯语言。 毕竟，我们只能通过支持昏迷语言来延长其寿命。 有时，最好按照原样与事物保持和平，然后放手。
从好的方面来说，Java“平台”是一个完全不同的故事。 在JVM上为其他编程语言提供一流支持的曾经雄心勃勃的目标已经成为现实。 感谢达芬奇项目（JSR 292）的努力。 这不仅使新语言易于实现，而且还利用了多年来改进Java运行时所积累的经验，解决了其某些本机性能问题。 如今，越来越多的语言在JVM上运行，其中的许多功能都可以满足未来的需求[5]。
毫无疑问，Java“平台”将超越Java“语言”。 有一天，我们将发现自己使用了没有Java的JVM。 用Martin Fowler的话说：“ Java的遗产将是平台，而不是语言”。 为了更好地理解这些内容，我建议在developerWorks [6]上使用Neal Ford的新系列java.next。
肾病
Java所要解决的问题的性质与其运行的硬件一样，对其未来的影响也很大。 作为一种通用编程语言，Java证明了自己适合几乎所有用例。 它在台式机上的历史性成功为企业取得更大的成功铺平了道路。 服务器端Java成熟了令人印象深刻的标准化API技术堆栈，可以满足最复杂需求的需求。 社会的兴起模糊了企业和消费者应用程序之间的界限，使后者变得更加复杂，甚至要求更高。 随着其他平台的苦苦挣扎，随着JEE 5的发布，JEE（Java企业版）变得更具吸引力，JEE 5将重点转移到了开发人员的生产力和轻量级。 云计算革命和PAAS的兴起是头等大事。 部署障碍变得无关紧要，这使得服务器端Java更加易于访问。
移动
长期以来，移动领域一直受到碎片化，硬件受限和数据连接不足的困扰。 只有其ME（微型版）版本的Java才能成功提供将所有功能结合在一起的编程模型。 在引入更智能的设备来密封其命运之前，移动Java一直享有多年的成功。 Java ME散布得如此之薄，它正努力跟上瞬息万变的形势，并发现自己无力履行其诺言。
具有讽刺意味的是，曾经发挥其优势的现在正在助长其灭亡。 在混乱中，Sun推出了JavaFX，这是一种旨在解决错误问题的新技术。 在没有Java手机的情况下，它专注于在每台设备上提供更丰富的平台，并且同样失败。 如今，JavaFX已大为不同。
在关键时刻，谷歌在Android背后投入了大量资源，并成功地填补了当时Java ME不足和JavaFX摇摇欲坠留下的空白。 没有人能否认它给“ Java”带来了急需的振兴，并把它介绍给了更广泛的受众。
有人可能会说Android是Java在移动领域的强大立足点。 只有当您碰巧认为Android是Java时，这才是正确的。 我不敢苟同。 在Android平台上，Java类被编译成类似于Java字节码的二进制文件，并在Dalvik上执行，该虚拟机不仅与标准JVM不同，而且在架构上不兼容。 此外，不完全支持Java标准类库（包括java.lang中的某些类），有时甚至以与Java SE开发人员相反的方式实现。 在这方面，Android通过选择Dalvik破坏了Java的灵魂。
我认为，Android不适合Java。 Android非常适合Android。 从某种意义上讲，它削弱了Java一直扮演的平台角色，并将其简化为该语言的语法，从而危及了移动Java的未来。 如果他或她考虑了范式转换的上下文，而赞成使用功能语言，则可以意识到损害的程度。 不质疑Google关于Android的意图是幼稚的。 不使用Java而选择使用Java的“业务”决策引起了很多疑问。 它的天才之处在于，它使他们可以以最小的风险获得最流行的编程语言的所有信誉。 同样重要的是要强调他们当时没有太多选择。
iPhone上的Java怎么样？ 苹果公司一直很珍惜Objective-C，这是它从NeXT时代继承下来的一种杂色编程语言。 没有人喜欢Objective-C，但是Apple不会做错事。 iOS平台的成功和美丽吸引我们忽略了该语言的丑陋和冗长。
能够在iOS平台上编写Java应用程序碰巧对Apple提出了太多要求，Apple既未在iOS设备上提供本机JVM，也不允许第三方自行移植它。 鉴于Google和Oracle最近就Java API发生专利争夺战[7]，并且该公司显然希望能够自给自足地依赖其控制的技术，这是可以理解的。
Java的创建者James Gosling在infoworld.com上发表的一篇文章中[8]提出，新的JEP（JDK增强建议）178可以成为Java的特洛伊木马，以征服守卫良好的iOS城堡。 增强功能旨在“修改Java SE规范和JDK（Java开发工具包），以使开发人员能够将Java运行时，本机应用程序代码和Java应用程序代码打包到一个不需要使用共享库的二进制文件中” 。
听起来这是一个不错的解决方法，但并非没有挑战。 我看到了几个严重的问题。 最明显的是，JVM二进制文件将显着增加最终可交付应用程序的大小。 自从2008年成立以来一直受到拖累的Project Jigsaw（JSR 337），实际上可以通过允许开发人员清除其应用程序不需要的JVM模块来消除此问题。 另一个令人担忧的问题是苹果臭名昭著的App Store批准程序，其条款随时可能更改。 如果该公司决定有一天开始从商店中启动所有Java应用程序，这也就不足为奇了。 如果我们假设应用程序的大小不是问题，并且Apple由于某种原因对Java友好，那么我们仍然必须面对编写与本地iOS应用程序质量相当的Java应用程序的挑战。
在Java上开发桌面和嵌入式应用程序的旗舰技术是JavaFX。 如果要用于编写iOS应用程序，我们将需要对iOS控件的支持以及与Apple设计指南一致的本机外观，需要利用Apple硬件的全功能API以及许多其他缺少的功能。 JavaFX带来的最重要的资产是在处理音频，视频，图形和动画方面的出色性能。 可以说，这是优于iOS平台所提供的东西。 不幸的是，这将是未开发的。 根据Gosling的说法，“必须关闭JIT代码生成器” [8]。 这使Java在iOS上处于极大的劣势，以至于最好改用类似PhoneGapHTML5技术。
我认为，至少可以说移动Java的状态。 最大的担心是，如果事情保持现状，我们将从Java在任何地方运行到Java无处运行！
房间里的大象
我不能以最近的安全漏洞不值得一提，或者Oracle没有通过Java起诉Google来结束本文。 请允许我休息一下。 随着早期报告的发布，恐惧的商人大喊：“禁用不安全的Java！” 像其他任何技术都不容易受到安全威胁。
除了讽刺，最近的大多数漏洞仅影响Java浏览器插件，客户端可以在其中下载不受信任的恶意代码并在其本地JVM中执行。 在一种情况下，可以反省地禁用安全管理器，为各种问题敞开大门。 听起来听起来很苛刻，但如果您在2013年仍在编写Java Applet，那么除了您自己，谁也应该怪别人。 鸡已经回家烤。 也许现在是时候考虑将软件作为Web应用程序交付了。
我并不是在说这是受害人指责或证明Oracle的搞砸了。 我特意冒犯他人，以提请注意这样一个事实，即依赖于客户端运行时的体系结构会带来这种风险。 Oracle通常是最重要的，并且通常在事件发生后的几天内发布补丁。 问题是，截至2013年3月25日，只有5.5％的浏览器运行的是最新版本的Java插件[9]。 不能否认开发人员有责任确保他或她的应用程序使用适当版本的运行时。 无法建立要求特定版本的JVM的机制或无法强制客户端进行更新的机制使得很难将其全部丢在Oracle的腿上。 如果您对更新和更多信息感兴趣，请查看Oracle软件安全性保证博客[10]中的最新信息。
Oracle对Sun Microsystems的收购使Java社区备受关注。 除了两家公司对开源软件的态度迥然不同外，Oracle对Sun的硬件更感兴趣并且对Java不太在意也已不是秘密。
早在2009年，我写了一篇题为“ Oracle / Sun合并社区观点的博客”的博客文章[11]，以在发布公告后的第一次OOW（Oracle开放世界）会议上记录我的印象。 无论如何，我的总体态度是保留的，有些不确定。 我对Java是开源的这一事实感到放心。
回顾过去，尽管有种种批评和猜测，但最终收购对Java还是有利的。 然而，Oracle的某些行动发出了混合信号。 通过不断地支持JUG，改进通信，改革和简化JSR流程，Oracle在开发技术和使社区参与方面所做的工作相当出色。 但是，它针对Google试图对Java API进行版权保护而提起的诉讼仅是对每个人的最初担忧的证实。 幸运的是，法院裁定Google认为Java API是非版权的，因为它们具有功能性，并且其他人也必须使用Java语言[12]。 我遇到的很多人都对法院的裁决感到宽慰。 在我看来，毫无疑问，要取决于Oracle，Java不会是开源的。 释放Java的决定仍然是Sun Microsystems的最大遗产。 RIP太阳！
Java Tasseography
如果通读这篇文章给您的印象是，我对Java的未来有一个明确的答案，对您的误导我深表歉意。 事实是我真的不知道，会说每个人都在猜测。 这是在马拉喀什的旧露天市场或者在斯托利皮诺沃大街上的算命先生更好地问一个问题的问题之一。
现在，您可以花时间阅读那杯热气腾腾的Java发出的可见蒸汽，问自己：“它真的像它看起来那么热吗？ 还是房间的温度太低？” 我说，当所有要散发的蒸气通过空气扩散时，先喝一口，然后喝一点凉。 我们都知道它已经存在了很长时间，不会灼伤您的舌头。
Que sera sera…
本文最初发表在6月版的《 JAX杂志》上 。
图片由waferboard
Abdelmoniam在本质上和专业上都是软件开发人员和技术爱好者，对技术传播，企业软件开发和体系结构特别感兴趣。 Abdel在Java企业应用程序和各种相关技术方面经验丰富。 他是NorCal Java用户组，硅谷Dart Meetup和硅谷Spring用户组等多个组织的总裁和创始人。 Abdel经常在许多开发人员会议上演讲，包括JavaOne（被称为JavaOne Rockstar），JAXConf，OSCon，OREDEV，以及许多用户组和社区活动。
参考文献
[1] http://99-bottles-of-beer.net/
[2] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
[3] http://www-03.ibm.com/press/us/en/pressrelease/41095.wss
[4] [3] http://oreilly.com/news/graphics/prog_lang_poster.pdf
[5] http://en.wikipedia.org/wiki/List_of_JVM_languages
[6] http://www.ibm.com/developerworks/library/j-jn1/
[7] http://www.computerworld.com/s/article/9239658/Computer_scientists_oppose_Orac le_39_s_bid_to_copyright_Java_APIs
[8] http://www.infoworld.com/t/java-programming/gosling-new-java-proposal-could-easy-ports-ios-213843
[9] http://community.websense.com/blogs/securitylabs/archive/2013/03/25/how-are- java-attacks-getting-through.aspx？cmpid = slbl
[10] https://blogs.oracle.com/security/entry/june_2013_critical_patch_update
[11] http://blog.polymathiccoder.com/post/53583500559/oracle-sun-merger-a- community-prospective [12] https://www.docketalarm.com/cases/California_Northern_District_Court/3-10- cv -03561 / Oracle_America_Inc_v_Google_Inc / 1190 /
翻译自: https://jaxenter.com/java-hasnt-lost-its-mojo-2-107048.html