spring javafx
我们确实在Codename One上依赖JavaFX，我们的模拟器需要它。 我们的桌面版本使用它，而我们的设计器工具基于Swing。 我们希望它成功，这对我们的业务至关重要！ 即使您是Java EE开发人员并且不关心桌面编程，我们也不是一个人，请记住一个事实，即今天的桌面技术就是明天的服务器技术。 例如：C ++和Windows（一种桌面技术）从Unix和C中获得了服务器。只能由Java（直到后来是基于Web的Applet语言）和Linux取代。 今天JavaScript可能看起来并不像JavaEE的竞争者，但是随着越来越多的开发人员从大学毕业后就喜欢JavaScript而不是Java，这将影响到我们所有人。
注意：如果您是JavaScript / NodeJS或任何其他此类脚本语言的狂热者，那么您不是本篇文章的目标读者……本篇文章适用于喜欢使用Java并希望其发展的人。
如果有的话，他们正在重新安排兴登堡的躺椅！
斯蒂芬·科尔伯特
当我们在JavaOne 2014上租用展位时，给人的印象是，与我们交谈的Java开发人员中有90％是企业开发人员。 大多数参展商和参加人数最多的演讲也是面向企业的。 作为移动工具供应商，这比台式机开发和移动设备之间的跨越要困难得多。 它强调了一个事实，我们需要JavaFX来工作或让其变得更好，但现在我们需要GUI解决方案。
这篇文章不是关于JavaFX是否糟透了。 它不是关于它是否是一个好的API，也不是关于是否可以使用它创建美观的应用程序。 它是关于修复JavaFX或将其转移到其他方面，它是关于承认其中的问题，而不是向新鲜的Java开发人员展示“一切都很好”的光环。
最初，我还撰写了有关JavaFX中的一些技术问题的文章。 我决定不参加那个讨论。 我对创建JavaFX的人表示敬佩和敬意。 其令人印象深刻的许多方面。 但是好的技术也会失败，在接下来的几节中，我将尝试详细阐述一下：
- 推理–为什么我们都需要Java桌面API策略
- 证明–如果您认为JavaFX的牵引力不存在严重问题，请阅读此文章
- 我们为什么要关心？ –如果您是Java EE开发人员，认为这与您无关，请阅读此内容。
- 有什么选择？ –我们如何推动Java向前发展。
- 我们是怎么来到这里的？ –如果您是Java的新手，并且本次讨论缺少历史背景，请首先阅读此内容。
- 最终决定-我个人对我在此处列出的事实的看法。
推理
解决问题的第一步是承认我们有一个问题，现在JavaFX是Java社区努力避免的问题。 Swing相当稳定，尽管有很多问题/陷阱，但它有自己的合理吸引力。 JavaFX仍未达到该状态，但是以防万一您与我不在同一页面上，我们将在下一部分中回顾证据。
这不是一篇容易写的文章，而且我相信它也不容易阅读，但是它只是Java社区中没有发生而应该发生的讨论。 每天真正引入Java的新开发人员都无法真正了解JavaFX的问题。 让我写这篇文章的是这篇博客文章 ， 这里Java Code Geeks对此进行了镜像。 我认为，尽管这篇文章是真实的（以非常主观的方式），但它也对JavaFX的状态和感知产生了错误的印象。 当我们试图说服年轻的学生学习Java时，这是非常令人不安的，我们不希望他们以后被幻灭。
如果我们不接受JavaFX的问题，将无法解决。 Java FX的当前用户包括3种原型：Swing投资巨大的公司，学生和顽固的顽固支持者。 尽管以上所有内容都很好，但是您不能基于此建立一个社区。 公司并没有在建设新事物，学生将毕业做其他事情，并成为铁杆粉丝……随着平台的衰退，他们可能一无所有。 我将在这篇文章中介绍“我们为什么要关心”，但首先请避免为铁杆粉丝讨论证明。
证明JavaFX没有牵引力
图表A：Oracle不使用JavaFX
我可以继续讨论，但是事实很清楚。 甚至基于Swing的Oracle产品也没有朝JavaFX的方向发展。 我可以发动福音传教士和Oracle内使用JavaFX的一些团队的工作，但这似乎是多余的。 我想指出的是，尽管Oracle不再分发Scene Builder，是的，我知道它仍然可以在其他地方使用，但是如果您正在寻找Oracle正在思考的迹象的话……消息非常清晰。
图表B：JavaFX尚未获得摇摆的动力
堆栈溢出是在“ 2008年9月15日”启动的，这很重要，因为JavaFX是在“ 2008年12月4日”发布的。 实际上，当FX凭借其所有PR荣耀而问世时，StackOverflow才是全新的，Swing应该一直在下降。 StackOverflow存在而JavaFX不存在的时间很少。
以上本质上意味着，与FX相比，Swing在StackOverflow上应具有更少的问题标签，令人惊讶的是，这里的数字非常令人震惊和具有决定性……JavaFX有11565个问题标签，对于一个已有7年历史的高度可见和广泛推广的项目来说，这是有意义的。 但是，应该在此期间下降的Swing产生了56,434个问题，这向我表明，即使是FX开发人员的CORE人口统计信息的Swing开发人员也没有迁移。
公平地说，JavaFX在JavaFX脚本和基于Java的JavaFX之间进行了转换。 但这应该引起社区中更多的问题和困惑。 可以说，“重新启动”引起了全世界的关注，应该已经映射到使用号。 Google趋势中的这张启发图确实标明了这一点：
请注意，Swing（具有一定的吸引力）下降了，JavaFX仍然很低，有效地竞争了对Swing的关注，而不是增长。 该图表可能被理解为“台式机失去了对移动和Web的兴趣”，这是正确的，并且可以作为答案（请参阅下面的讨论），但是FX甚至无法击败Swing的事实表明，存在更大的问题。 但是，让我们将其与处于类似情况下的另一家公司比较，该公司的桌面导向工具很受欢迎，并被网络/移动电话所扫地：
如您所见，根据Google的（不科学的）趋势，恶意程度较高的Adobe Flash比Swing / FX更重要。
图表C：Dice.com同意
虽然我认为您不应该因为就业市场而选择技术，但这表明了市场的状况。 在dice.com上搜索JavaFX获得了28个职位，其中只有4个职位将Java FX作为工作的要求（我只有一个，一个就检查了一个，只有28个！）。 “ Java FX”仅列出了12个选项。 但这就是有趣的地方了……Swing拥有198个职位！ JavaEE有16,752个职位，Android有2,333个职位。
公平地讲，有一个NASA承包商的工作在Java FX搜索中看起来确实很不错，但是我认为上述所有结论都表明JavaFX缺乏吸引力 。
我们为什么要关心？
如果您是JavaFX的粉丝，那么这是不二之选。 向前跳。 但是我们其他人应该深切关注，因为桌面编程对于整个Java生态系统的健康至关重要。 Java的一大优点是在移动设备，台式机和后端之间的技能转移/工具可移植性。 作为开发人员，我们在数据中心和前台之间移动的能力在我们的行业中是无与伦比的！
Java现在在所有方面都面临挑战：服务器端的NodeJS / Ruby等，移动设备上的iOS和移动设备和台式机上HTML + JavaScript。 如果客户团队未使用Java编写应用程序，那么为什么要在服务器上使用Java？ 客户团队和服务器团队使用相同的语言会不会更方便？
是的，移动设备在这里起了很大的作用，而JavaFX（或台式机）将无法从网络上接管。 但是，在企业崛起之后，随着Web的崛起，Swing占据了主导地位，而JavaFX却失去了这一优势。 失去这种优势可能会使Oracle在这个利润丰厚的JavaEE市场上付出代价，并且由于我们特定的技能经验较少的需求而可能使我们的技能下降（是的，我们仍然像COBOL那样赚钱，但事实并非如此）在最先进的系统上维护旧系统非常有趣）。
我们仍然需要一个桌面开发API来构建我们的IDE，我们的控制台并在我们的计算机上执行几乎所有操作。 桌面开发API也是巨大的教学辅助工具，与部署某些Web服务相比，启动和运行UI对教学过程的影响更大。 如果您希望下一代Java开发人员，我们需要一个不错的UI选项。 你们当中的一些JavaEE开发人员（或扮演框架迷）可能会跳上HTML潮流来进行教学……
我认为这是比讲授Java FX更好的解决方案，但实际上它比台式机编程还难，因此您将直接与具有“家庭法院优势”JavaScript工具竞争，因为学生可能更愿意学习2种语言而不是3种语言（HTML +仅限JavaScript）。 今天的学生有时在课堂上学习JavaFX或Swing，并且经常发现他们离开教室时学习了昨天的技术！ 即使您从未打算编写这样的UI，使用Java编写Java的能力对于所有Java开发人员也至关重要！
有什么选择？
希望您到此为止（至少部分地）同意存在问题。 我认为问题之一是来自Oracle的关于其对JavaFX的承诺（或缺乏承诺）的消息不明确。 他们的代表非正式地说Oracle永远不会停止生产产品。 那是很准确的。 但是，Swing已经几乎被遗弃了，而且感觉就是这样。
修复并推广JavaFX
只有Oracle可以做到这一点。 尽管Java比Oracle强大，并且即使Oracle停止了所有活动，Java仍将继续存在，但JavaFX不能说相同。 社区已经进行了一段时间的努力，但是像JavaFX这样的野心勃勃的项目需要认真的支持，如果Oracle无法落后于JavaFX 100％，那么它将不断下降并拖累Java。
承认JavaFX永远不会接手
这就是我所提倡的。 JavaFX在这里保持与AWT相同的方式，但是一旦我们接受了它永远不会超过其当前有限范围的情况，这便为Java客户端开发提供了可能性。 这也意味着我们应该开始关注新事物，也许某些事物可能会替代新事物。
我认为，最重要的是将学生从JavaFX转移到Java的更可持续发展领域，例如更新的服务器/ HTML框架或移动领域，这仍将为您提供一些令人愉悦的“麻木”体验用户界面可以运行，但可以提供更可持续的技能。 我花了几天时间试图在台式机上提出JavaFX的潜在替代方案，但不幸的是，目前还没有真正的竞争者。 也许我在下面列出的竞争者之一将完成这项任务：
- SWT – SWT尚未成熟。 在设计时，将其建模为Win32 API似乎是正确的选择，但随着向移动和Mac的迁移，它现在已成为一个有问题的竞争者。 它虽然成熟，但众所周知。
- 摇摆-返回摇摆可能不是一种选择，因为已经花费了太多时间。 由于它与JDK集成在一起，因此任何东西都需要进入JVM并通过Oracle。
- QT –在我的C ++时代，我曾经非常喜欢QT。 自那以来，它增加了一些东西，但是自从诺基亚购买以来，它大部分都固定在原处。 此外，大多数代码库都是C ++的事实使得对于大多数Java开发人员来说，这并不是一个开始。
- 本机-实际上，我们正在考虑将其用于Codename Ones桌面端口。 只需使用Java本地映射API直接调用OS本机API。 对于Codename One，这非常简单，因为我们可以使用Open GL，并且使用的同行很少，但是我认为这对整个Java开发人员都不有用。
- HTML5 –我认为JavaScript在HTML方面具有巨大优势。 如果HTML或浏览器是主导者，那么为什么要使用Java？ JavaScript在HTML世界中已经具有吸引力和工具包，而Java在那儿似乎有些陌生。
- DukeScript / TeaVM / GWT –我真的很喜欢所有这些功能，并且与HTML集成的功能很强大，但是我认为将所有精力都集中在这些工具上最终可以将Java替换为看起来像贬义的咖啡脚本替代品。
- Android –像代号一样，不是为桌面设计的。 但与我们不同的是，它已适应台式机（根据传闻取代了Chrome操作系统）。 它是一个庞大，复杂且相当完整的API，缺少一些关键功能，但功能仍然非常强大。 唯一的问题是，这既需要移植工作，又需要将桌面“概念”添加到非常映射到移动设备的API（Windows等）中，这需要大量的工作。
我们是怎么来到这里的？
对于大多数读者来说，本节可能是多余的，但在写完以上所有内容之后，我发现一个刚读完我的文章的Java开发人员几乎没有什么历史背景。 幸运的是，在Java FX的预览期间，我在Sun Microsystem和Oracle担任前排席位，因为未能实现，所以我可以很容易地回顾历史。
Java与AWT一起发布，这是一个非常有问题的“冲向市场” GUI API。 Sun希望改进AWT并用Swing替代它，不幸的是，当时Netscape（领先的浏览器供应商，利润颇丰）已经在Java 1.1上进行了标准化，而Microsoft也被困在那儿。
因此，Swing是经过折衷开发的，旨在使其能够在当时是Java的主要用户的浏览器中工作。 这点历史很重要，因为它可以完美地解决FX中的问题。 大约十年前，Chris Oliver（Sun工程师）介绍了他编写的一种相当酷的脚本语言，并在Sun中获得了一定的吸引力。 当时，Swing在企业中很受欢迎，但在消费者市场上逐渐失去了Flash的地位。
Sun的经理们决定推广这种想法，并为这种新语言投入了大量的精力和资源，最终将其命名为JavaFX Script。 从Swing中删除了许多开发人员资源，并将其放入JavaFX脚本项目中，并向开发人员做出了很多承诺。 我实际上帮助了一些相关项目，例如手机端口等。
JavaFX Script存在许多问题，Sun的麻烦以及众所周知的宽松管理风格进一步加剧了这些问题。 随着Oracle收购Sun，SwingSwift下降。 Oracle取消了JavaFX脚本，但是喜欢它背后的许多API想法，因此他们将JavaFX的工作重新定位为基于Java的API。 通常，这是一个好主意，但以典型的公司方式，每个使用JavaFX Script的人都必须立即将其应用程序移植到新的JavaFX上，否则就无法下载VM（在后来他们撤消了这个决定，但这并不是最好的方法，但是无法下载VM）。对待早期的适配器）。
新的JavaFX API花费了很多年才实现，而且有一段时间甚至没有开放或未正确集成到JDK中。 到目前为止，它的集成还只是其中的一部分，它仍然不是Open JDK（在Linux上很重要）的一部分。
当JavaFX团队组建并成长时，他们做出了一个重要的决定，后来又困扰了他们：不要重蹈Swing / AWT的覆辙-构建一个干净的API，不受遗留的负担。 不幸的是，作为发达国家一家大型公司的产品，他们需要支持很多东西（例如可访问性），因此需要从头开始编写大量代码。
因此，该团队创建了一个设计良好的API，但是没有向Swing开发人员提供良好的迁移途径，并且从某种程度上来说，从Swing到今天仍然存在（尽管有很多改进）。 该API庞大，但在某些部分仍不完整，因为此类API所需的宽度。 同时，多年来没有任何实际更新的Swing开发人员大部分都转移到了其他平台上，现在我们拥有Swing和FX，其中一个已经过时，而另一个品牌却崭新，但没有真正的吸引力。
我认为JavaFX的最大教训是始终“精打细算”并经常发布。 即使您拥有Sun / Oracle可以使用的全套资源，从一开始就尝试构建完整的解决方案也很少见。 我认为JavaFX中的所有问题都是管理不善的结果。
最后的话
在拉里·佩奇（Larry Page）的带领下，我最讨厌Google的事情之一是Spring大扫除，因为Android Google未能创造出具有这种吸引力的产品。 那不是由于缺乏尝试，而是由于缺乏对任何事物的承诺。 大多数人不记得这一点，但是Android最初发布时（G1）就是一个失败，而iPhone的关注度很小（相对于整个移动市场而言）。 两家公司都坚持了下去，并在缓慢地迭代产品的同时投资了产品/伙伴关系。 这花费了金钱，时间和承诺，这很难做到。
不幸的是，请查看JavaFX的当前状态以及Oracle对其的支持。 很明显，它已经移至维护模式，并且无法获得增长所需的资源。 我认为我们最好将其移到一边，让其他技术脱颖而出。 即使您不同意这种观点，我希望我们都同意这里存在严重问题。 对我来说，问题主要在于学生通过大学或在线课程学习JavaFX。 我们不妨教他们COBOL，也有写COBOL的工作。
鉴于JavaFX的当前状态以及缺乏竞争者来占据其空间（目前尚未正式空缺），我感到我们可能会一事无成。 至少到那时，我们的桌面API应该驻留在其虚拟前院中有一个很大的“空缺”迹象。 这将使我上面列出的选项之一（或全新的选项）占据那个位置……也许会触发Oracle的某个人最终为JavaFX提供将其转变为可行工具所需的资源，但知道Oracle…我不持有我的呼吸。
翻译自: https://www.javacodegeeks.com/2015/11/should-oracle-spring-clean-javafx.html
spring javafx