當前位置：首頁 > 编程语言 > java >内容正文

java

java7和java8切换_仍不切换到Java 8的6个理由

發布時間：2023/12/3 java 25 豆豆

生活随笔收集整理的這篇文章主要介紹了 java7和java8切换_仍不切换到Java 8的6个理由小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

java7和java8切換

Java 8很棒。期。但是……在我們有機會玩耍并玩弄它之后，就該退出了，避免吃鹽。所有的好東西都是有代價的，在這篇文章中，我將分享Java 8的主要痛點。請確保在升級和釋放7之前您已經意識到了這些痛點。

1.并行流實際上會使您減速

Java 8將并行性作為最令人期待的新功能之一帶來了希望。 .parallelStream（）方法在集合和流上實現此目的。它將它們分解為子問題，然后在單獨的線程上運行以進行處理，它們可以進入不同的核心，然后在完成后組合在一起。這一切都是在使用fork / join框架進行的。聽起來不錯，它必須加快多核環境中大型數據集的操作，對嗎？

不，如果使用不正確，它實際上會使代碼運行速度變慢。慢上大約15％這個基準，我們跑了，但它可能會更糟糕。假設我們已經在運行多個線程，并且在其中一些線程中使用了.parallelStream（），從而向池中添加了越來越多的線程。這很容易變成我們的核心無法處理的事情，并且由于上下文切換的增加而減慢了一切。

基準測試速度較慢，將集合分為不同的組（素數/非素數）：

Map<Boolean, List<Integer>> groupByPrimary = numbers .parallelStream().collect(Collectors.groupingBy(s -> Utility.isPrime(s)));

同樣，由于其他原因，還會出現更多的變慢。考慮到這一點，假設我們有多個任務要完成，由于某種原因，其中一個要比其他任務花費更長的時間。用.parallelStream（）分解實際上可能延遲完成較快的任務以及整個過程。請查看Lukas Krecan的這篇文章，以獲取更多示例和代碼示例。

診斷：并行性及其所有優點也帶來了其他類型的問題需要考慮。當已經在多線程環境中執行操作時，請記住這一點，并使自己熟悉幕后發生的事情。

2. Lambda表達式的反面

Lambdas。哦，lambdas。如果沒有您，我們幾乎可以完成所有本來可以做的事，但是您卻增加了很多寬限期，并且擺脫了樣板代碼，因此很容易墜入愛河。假設我早上起來，想遍歷一隊世界杯球隊并確定他們的身長（有趣的事實：總數達到254）：

List lengths = new ArrayList();for (String countries : Arrays.asList(args)) {lengths.add(check(country)); }

現在讓我們通過一個很好的lambda來實現功能：

Stream lengths = countries.stream().map(countries -> check(country));

寶貝！太好了盡管……雖然通常被視為是一件好事，但在Java中添加諸如lambdas之類的新元素會使它進一步偏離其原始規范。字節碼是完全OO的，并且在游戲中帶有lambda，因此實際代碼與運行時之間的距離會越來越大。在Tal Weiss的這篇文章中閱讀有關lambda表達的黑暗面的更多信息。

最重要的是，這一切都意味著您正在編寫的內容和正在調試的內容是兩件事。堆棧跟蹤越來越大，使調試代碼變得更加困難。

簡單的操作（例如，向列表中添加空字符串）將使此簡短的堆棧跟蹤成為可能：

at LmbdaMain.check(LmbdaMain.java:19) at LmbdaMain.main(LmbdaMain.java:34)

變成這個：

at LmbdaMain.check(LmbdaMain.java:19) at LmbdaMain.lambda$0(LmbdaMain.java:37) at LmbdaMain$$Lambda$1/821270929.apply(Unknown Source) at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:512) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:502) at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.LongPipeline.reduce(LongPipeline.java:438) at java.util.stream.LongPipeline.sum(LongPipeline.java:396) at java.util.stream.ReferencePipeline.count(ReferencePipeline.java:526) at LmbdaMain.main(LmbdaMain.java:39)

lambda引發的另一個問題與重載有關：由于lambda參數在使用它們調用方法時必須轉換為某種東西，并且它們可以轉換為多種類型，因此在某些情況下可能導致模棱兩可的調用。 Lukas Eder 在此處通過代碼示例對此進行了解釋。

診斷：僅需注意這一點，痕跡可能會不時帶來痛苦，但不會使我們遠離它們。

3.默認方法會分散注意力

默認方法在接口本身中啟用功能的默認實現。這無疑是Java 8帶來的最酷的新功能之一，但它在某種程度上干擾了我們過去的工作方式。那么為什么要引入這個呢？那與它無關嗎？

默認方法背后的主要動機是，如果在某個時候我們需要向現有接口添加方法，則無需重寫實現就可以做到這一點。與舊版本兼容。例如，從Oracle Java教程中獲得以下這段代碼，它們在其中添加了指定時區的功能：

public interface TimeClient { // ... static public ZoneId getZoneId (String zoneString) { try {return ZoneId.of(zoneString); } catch (DateTimeException e) {System.err.println("Invalid time zone: " + zoneString +"; using default time zone instead.");return ZoneId.systemDefault();} }default public ZonedDateTime getZonedDateTime(String zoneString) {return ZonedDateTime.of(getLocalDateTime(), getZoneId(zoneString));} }

就是這樣，問題解決了。還是？默認方法混淆了接口和實現的分離。在錯誤的手中，仿佛類型層次結構不會自己糾結，現在我們需要馴服這個新生物。在Oleg Shelajev在RebelLabs上的帖子中了解更多有關它的信息。

診斷：當您拿著錘子時，一切看起來都像釘子，請牢記堅持其原始用例，當重構引入一個新的抽象類時，現有接口的演變毫無意義。

繼續進行一些遺失，仍在我們身邊或尚未完全存在的事情：

4.為什么您是

Jigsaw項目的目標是使Java模塊化并將JRE分解為可互操作的組件。首先，其背后的動機來自對更好，更快，更強大的 Java嵌入式的渴望。我試圖避免提及“物聯網”，但是我在那說了。減小JAR大小，提高性能和提高安全性是這個雄心勃勃的項目所具有的更多希望。

那在哪呢 Oracle首席Java架構師Mark Reinhold說，拼圖剛進入了第二階段，已經通過了探索階段，現在正在將其轉換為生產質量設計和實現。該項目最初計劃在Java 8中完成，然后推遲到Java 9，有望成為其旗艦新功能之一。

診斷：如果這是您要等待的主要內容，則Java 9將于2016年推出。與此同時，仔細研究一下，甚至可能會加入Jigsaw-dev郵件列表。

5.仍然存在的問題

檢查異常

沒有人喜歡樣板代碼，這就是lambda如此受歡迎的原因之一。考慮樣板異常，無論邏輯上是否需要捕獲或與檢查異常相關，您仍然需要捕獲它。即使這是永遠不會發生的事情，例如永遠不會觸發的異常：

try {httpConn.setRequestMethod("GET"); }?catch (ProtocolException pe) { /* Why don’t you call me anymore? */ }

原語

它們仍然在這里，正確使用它們很痛苦。將Java與純粹的面向對象的語言區別開來的一件事是，批評說Java的刪除對其性能沒有重大影響。只是說，所有新的JVM語言都沒有它們。

運算符重載

Java的父親James Gosling在一次采訪中說：“我忽略了運算符重載，這是一個非常個人的選擇，因為我看到太多的人在C ++中濫用它”。有點道理，但是對此有很多不同意見。其他JVM語言確實提供了此功能，但另一方面，它可能會導致代碼如下所示：

javascriptEntryPoints <<= (sourceDirectory in Compile)(base =>((base / "assets" ** "*.js") --- (base / "assets" ** "_*")).get )

來自Scala Play框架的實際代碼行，嗯，我現在有點頭暈。

診斷：這些是否是真正的問題？我們都有自己的怪癖，這些都是Java的怪癖。在將來的版本中可能會發生意外的情況，并且會有所變化，但是其他方面的向后兼容性使它們一直在我們身邊。

6.函數式編程–還不完全

盡管以前很尷尬，但以前使用Java可以進行函數式編程。 Java 8借助lambda對此進行了改進。這是最受歡迎的，但沒有以前描述的那么大。絕對比Java 7更優雅，但仍需要向后彎曲才能真正發揮作用。

關于此問題的最激烈的評論之一來自Pierre-yves Saumont，他在一系列文章中仔細研究了函數式編程范例與在Java中實現它們之間的區別。

那么Java還是Scala？ Java中采用功能更強大的現代范例對于已經使用lambda的Scala表示認可。 Lambda確實引起了很大的反響，但是還有很多特性，例如特征，懶惰的評估和不可變的特性等，它們會帶來很大的不同。

診斷：不要被lambda分散注意力，在Java 8中函數式編程仍然很麻煩。

翻譯自: https://www.javacodegeeks.com/2014/07/6-reasons-not-to-switch-to-java-8-just-yet.html