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

總結

以上是生活随笔為你收集整理的spring javafx_Oracle Spring Clean JavaFX应该吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。