北京网站制作 建设推广,网站缓存设置怎么做,微信开发流程四步,个人网站盈利我们确实在Codename One上依赖JavaFX#xff0c;我们的模拟器需要它。 我们的桌面版本使用它#xff0c;而我们的设计器工具基于Swing。 我们希望它成功#xff0c;这对我们的业务至关重要#xff01; 即使您是Java EE开发人员并且不关心桌面编程#xff0c;我们也不是一个… 我们确实在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没有牵引力 图表AOracle不使用JavaFX 我可以继续讨论但是事实很清楚。 甚至基于Swing的Oracle产品也没有朝JavaFX的方向发展。 我可以发动福音人员和甲骨文公司内部的一些使用JavaFX的团队的解雇但这似乎是多余的。 我想指出的是尽管Oracle不再分发Scene Builder是的我知道它仍然可以在其他地方使用但是如果您正在寻找Oracle正在思考的迹象的话……消息传递非常清晰。 图表BJavaFX尚未获得发展的动力 堆栈溢出是在“ 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更重要。 图表CDice.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失去了这一优势。 失去这种优势可能会使甲骨文在这个利润丰厚的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 –像代号一样Android不是为台式机设计的。 但与我们不同的是它已适应台式机根据传闻取代了Chrome操作系统。 它是一个庞大复杂且相当完整的API缺少一些关键功能但仍然非常强大。 唯一的问题是在移植工作和向非常映射到移动设备的APIWindows等中添加桌面“概念”方面这都需要付出大量的努力。 我们是怎么来到这里的 对于大多数读者来说本节可能是多余的但是在写完以上所有内容之后我发现一个刚读完我的文章的Java开发人员几乎没有什么历史背景。 幸运的是在Java FX的预览期间我在Sun Microsystem和Oracle担任前排席位因为未能实现所以我可以很容易地回顾历史。 Java与AWT一起发布这是一个非常有问题的“冲向市场” GUI API。 Sun希望改进AWT并用Swing代替它不幸的是当时Netscape领先的浏览器供应商利润颇丰已经在Java 1.1上进行了标准化而Microsoft也被困在那儿。 因此Swing是经过折衷开发的旨在使其能够在当时是Java的主要用户的浏览器中工作。 这一点历史很重要因为它可以完美地解决FX中的问题。 大约十年前Chris OliverSun工程师介绍了他编写的一种很酷的脚本语言并在Sun中获得了一定的吸引力。 当时Swing在企业中很受欢迎但在消费者市场上逐渐失去了Flash的地位。 Sun的经理们决定推广这种想法并为这种新语言投入了大量的精力和资源最终将其命名为JavaFX Script。 从Swing中删除了许多开发人员资源并将其放入JavaFX脚本项目中并向开发人员做出了很多承诺。 我实际上帮助了一些相关项目例如手机端口等。 JavaFX Script存在许多问题Sun的麻烦以及众所周知的宽松管理风格进一步加剧了这些问题。 随着Oracle收购SunSwingSwift下降。 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
