คำถามติดแท็ก java8

เราเพิ่งย้ายไปยัง Java 8 ตอนนี้ฉันเห็นแอปพลิเคชันที่เต็มไปด้วยOptionalวัตถุ ก่อน Java 8 (สไตล์ 1) Employee employee = employeeServive.getEmployee(); if(employee!=null){ System.out.println(employee.getId()); } หลังจาก Java 8 (สไตล์ 2) Optional<Employee> employeeOptional = Optional.ofNullable(employeeService.getEmployee()); if(employeeOptional.isPresent()){ Employee employee = employeeOptional.get(); System.out.println(employee.getId()); } ฉันไม่เห็นคุณค่าที่เพิ่มขึ้นของOptional<Employee> employeeOptional = employeeService.getEmployee();เวลาที่บริการกลับมาเป็นตัวเลือก: มาจากพื้นหลัง Java 6 ฉันเห็นสไตล์ 1 ชัดเจนกว่าและมีโค้ดน้อยกว่า มีข้อได้เปรียบที่แท้จริงที่ฉันหายไปที่นี่หรือไม่? รวบรวมจากความเข้าใจจากคำตอบทั้งหมดและการวิจัยเพิ่มเติมที่บล็อก

110 java  java8 

ใน Java 8 อินเทอร์เฟซสามารถมีวิธีการใช้งานวิธีการแบบคงที่และวิธีการที่เรียกว่า "เริ่มต้น" (ซึ่งชั้นเรียนการดำเนินการไม่จำเป็นต้องแทนที่) ในมุมมองของฉัน (อาจไร้เดียงสา) ไม่จำเป็นต้องละเมิดส่วนต่อประสานเช่นนี้ การเชื่อมต่อเป็นสัญญาที่คุณต้องปฏิบัติตามเสมอและนี่คือแนวคิดที่เรียบง่ายและบริสุทธิ์ ตอนนี้มันเป็นการผสมผสานของหลายสิ่งหลายอย่าง ในความเห็นของฉัน: วิธีการคงที่ไม่ได้เป็นของอินเตอร์เฟซ พวกมันอยู่ในคลาสยูทิลิตี้ ไม่ควรอนุญาตวิธีการ "เริ่มต้น" ในอินเทอร์เฟซเลย คุณสามารถใช้คลาสนามธรรมสำหรับวัตถุประสงค์นี้ได้เสมอ ในระยะสั้น: ก่อน Java 8: คุณสามารถใช้คลาสนามธรรมและคลาสปกติเพื่อจัดเตรียมเมธอด static และ default บทบาทของอินเตอร์เฟสชัดเจน วิธีการทั้งหมดในอินเทอร์เฟซควรจะ overriden โดยการใช้คลาส คุณไม่สามารถเพิ่มวิธีการใหม่ในอินเทอร์เฟซโดยไม่ต้องปรับเปลี่ยนการใช้งานทั้งหมด แต่นี่เป็นสิ่งที่ดีจริงๆ หลังจาก Java 8: ไม่มีความแตกต่างระหว่างอินเทอร์เฟซและคลาสนามธรรม (นอกเหนือจากมรดกหลายรายการ) ในความเป็นจริงคุณสามารถเลียนแบบคลาสปกติด้วยอินเทอร์เฟซ เมื่อตั้งโปรแกรมการใช้งานโปรแกรมเมอร์อาจลืมแทนที่วิธีการเริ่มต้น มีข้อผิดพลาดในการคอมไพล์ถ้าคลาสพยายามใช้อินเตอร์เฟสสองอินเตอร์เฟสขึ้นไปที่มีเมธอดดีฟอลต์ที่มีลายเซ็นเดียวกัน โดยการเพิ่มวิธีการเริ่มต้นให้กับส่วนติดต่อทุกชั้นใช้งานโดยอัตโนมัติสืบทอดพฤติกรรมนี้ คลาสเหล่านี้บางคลาสอาจไม่ได้รับการออกแบบโดยคำนึงถึงฟังก์ชันการทำงานใหม่และอาจทำให้เกิดปัญหาได้ ตัวอย่างเช่นถ้ามีคนเพิ่มวิธีการเริ่มต้นใหม่default void foo()ให้กับอินเทอร์เฟซIxจากนั้นชั้นเรียนCxดำเนินการIxและมีfooวิธีการส่วนตัวที่มีลายเซ็นเดียวกันจะไม่รวบรวม อะไรคือสาเหตุหลักที่ทำให้เกิดการเปลี่ยนแปลงครั้งใหญ่และพวกเขาจะได้ประโยชน์อะไรบ้าง (ถ้ามี)

99 java  programming-languages  interfaces  java8 

ในjava.util.functionแพ็คเกจของ Java 8 เรามี: ฟังก์ชัน : รับหนึ่งอาร์กิวเมนต์สร้างผลลัพธ์เดียว ผู้บริโภค : รับหนึ่งอาร์กิวเมนต์สร้างอะไรขึ้นมา ผู้จัดจำหน่าย : ไม่ต้องโต้เถียงสร้างผลลัพธ์เดียว ... : กรณีอื่น ๆ ที่จัดการแบบดั้งเดิมอาร์กิวเมนต์ 2 ข้อ ฯลฯ ... แต่ฉันต้องจัดการกับ " ไม่มีข้อโต้แย้งสร้างอะไร " ไม่มีอะไรสำหรับสิ่งนี้java.util.functionnalค่ะ ดังนั้นคำถามคือ: ชื่อ ' ฟังก์ชั่นที่ไม่โต้แย้งและไม่ส่งคืนอะไร '? ใน Java 8 นิยามของมันจะเป็น: @FunctionalInterface public interface InsertANameHere { void execute(); } ผู้บริหารอยู่แล้วและมีวัตถุประสงค์อื่น: " วัตถุที่ดำเนินการส่งงานที่เรียกใช้งานได้ " ลายเซ็นไม่ตรงกัน ( …

80 java  functional-programming  java8 

Java 8 มีไลบรารีใหม่ทั้งหมดสำหรับวันที่และเวลาในแพคเกจ java.time ซึ่งเป็นสิ่งที่น่ายินดีอย่างมากสำหรับทุกคนที่ต้องใช้ JodaTime มาก่อนหรือสร้างความยุ่งยากด้วยการทำให้เป็นวิธีการประมวลผลตัวช่วยนัดเดทเอง ชั้นเรียนจำนวนมากในแพ็คเกจนี้เป็นตัวแทนของการประทับเวลาและมีวิธีการช่วยเหลือที่getHour()จะได้รับชั่วโมงจากการประทับเวลาที่getMinute()จะได้รับนาทีจากการประทับเวลาที่getNano()จะได้รับ nanos จากการประทับเวลา ฯลฯ ... ฉันสังเกตเห็นว่าพวกเขาไม่มีวิธีที่เรียกว่าgetMillis()รับมิลลิวินาทีของการประทับเวลา แต่จะต้องมีวิธีการโทรget(ChronoField.MILLI_OF_SECOND)แทน สำหรับฉันดูเหมือนว่าไม่สอดคล้องกันในห้องสมุด ไม่มีใครรู้ว่าทำไมวิธีการดังกล่าวหายไปหรือเป็น Java 8 ยังอยู่ในการพัฒนามีความเป็นไปได้ที่จะเพิ่มในภายหลัง? https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html คลาสที่กำหนดไว้ที่นี่แสดงถึงแนวคิดหลักของวันที่และเวลารวมถึงอินสแตนซ์, ระยะเวลา, วันที่, เวลา, เขตเวลาและช่วงเวลา พวกเขาใช้ระบบปฏิทิน ISO ซึ่งเป็นปฏิทินโลกตามความเป็นจริงตามกฎเกรกอเรียน ชั้นเรียนทั้งหมดไม่เปลี่ยนแปลงและปลอดภัยต่อเธรด แต่ละอินสแตนซ์เวลาของวันที่ประกอบด้วยฟิลด์ที่ APIs ให้บริการ สำหรับการเข้าถึงระดับล่างไปยังฟิลด์อ้างถึงjava.time.temporalแพคเกจ แต่ละชั้นเรียนมีการสนับสนุนสำหรับการพิมพ์และการแยกวิเคราะห์ทุกวันและเวลา อ้างถึงjava.time.formatแพ็คเกจสำหรับตัวเลือกการปรับแต่ง ... ตัวอย่างของคลาสประเภทนี้: https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html วันที่และเวลาที่ไม่มีเขตเวลาในระบบปฏิทิน ISO-8601 เช่น 2007-12-03T10: 15: 30 LocalDateTimeเป็นออบเจ็กต์วันที่และเวลาที่ไม่เปลี่ยนรูปแบบซึ่งแสดงถึงวันที่และเวลาซึ่งมักถูกมองว่าเป็นปีเดือนเดือนวันชั่วโมงนาทีวินาที ฟิลด์วันที่และเวลาอื่น ๆ เช่นวันของปีวันของสัปดาห์และสัปดาห์ของปีก็สามารถเข้าถึงได้เช่นกัน เวลาแสดงด้วยความแม่นยำระดับนาโนวินาที ตัวอย่างเช่นค่า …

64 java  java8 

วิธีการอ้างอิงข้ามค่าใช้จ่ายของเสื้อคลุมแลมบ์ดา? พวกเขาอาจจะในอนาคตหรือไม่ อ้างอิงจากการสอนของ Java เกี่ยวกับวิธีการอ้างอิง : บางครั้ง ... การแสดงออกแลมบ์ดาไม่ทำอะไรเลยนอกจากเรียกวิธีการที่มีอยู่ ในกรณีเหล่านั้นมักจะชัดเจนกว่าในการอ้างอิงถึงวิธีการที่มีอยู่ตามชื่อ การอ้างอิงวิธีใช้ทำให้คุณสามารถทำได้ มันเป็นแลมบ์ดาขนาดกะทัดรัดและอ่านง่ายสำหรับวิธีการที่มีชื่ออยู่แล้ว ฉันชอบไวยากรณ์แลมบ์ดากับไวยากรณ์การอ้างอิงเมธอดด้วยเหตุผลหลายประการ: แลมบ์ดานั้นชัดเจนขึ้น แม้จะมีการอ้างสิทธิ์ของออราเคิล แต่ฉันพบว่าแลมบ์ดาไวยากรณ์นั้นง่ายต่อการอ่านมากกว่าการอ้างอิงวิธีการออบเจ็กต์สั้น ๆ เพราะไวยากรณ์การอ้างอิงเมธอดนั้นไม่ชัดเจน: Bar::foo คุณกำลังเรียกวิธีการหนึ่งอาร์กิวเมนต์คงที่ในชั้นเรียนของ x และผ่านมันได้หรือไม่ x -> Bar.foo(x) หรือคุณกำลังเรียกวิธีการเป็นศูนย์อาร์กิวเมนต์บน x? x -> x.foo() ไวยากรณ์การอ้างอิงเมธอดสามารถยืนอยู่ได้ทั้งอันใดอันหนึ่ง มันซ่อนสิ่งที่รหัสของคุณกำลังทำอยู่ แลมบ์ดาปลอดภัยกว่า หากคุณอ้างอิง Bar :: foo เป็นวิธีการเรียนและ Bar ภายหลังเพิ่มวิธีการตัวอย่างที่มีชื่อเดียวกัน (หรือในทางกลับกัน) รหัสของคุณจะไม่รวบรวมอีกต่อไป คุณสามารถใช้ lambdas อย่างสม่ำเสมอ คุณสามารถห่อฟังก์ชั่นใด ๆ ในแลมบ์ดา - เพื่อให้คุณสามารถใช้ไวยากรณ์เดียวกันได้ทุกที่ …

56 java  performance  syntax  lambda  java8 

ฉันขอขอบคุณฟีเจอร์ Java 8 ใหม่มากมายเกี่ยวกับ lambdas และอินเตอร์เฟสเมธอดดีฟอลต์ แต่ฉันยังคงเบื่อกับข้อยกเว้นที่ตรวจสอบ ตัวอย่างเช่นหากฉันต้องการแสดงรายการเขตข้อมูลที่มองเห็นได้ทั้งหมดของวัตถุที่ฉันต้องการจะเขียนสิ่งนี้: Arrays.asList(p.getClass().getFields()).forEach( f -> System.out.println(f.get(p)) ); แต่เนื่องจากgetวิธีการอาจมีข้อยกเว้นการตรวจสอบซึ่งไม่เห็นด้วยกับConsumerสัญญาอินเตอร์เฟซดังนั้นฉันต้องจับข้อยกเว้นนั้นและเขียนรหัสต่อไปนี้: Arrays.asList(p.getClass().getFields()).forEach( f -> { try { System.out.println(f.get(p)); } catch (IllegalArgumentException | IllegalAccessException ex) { throw new RuntimeException(ex); } } ); อย่างไรก็ตามในกรณีส่วนใหญ่ฉันแค่ต้องการยกเว้นจะถูกโยนเป็นRuntimeExceptionและให้โปรแกรมจัดการหรือไม่ยกเว้นโดยไม่มีข้อผิดพลาดในการรวบรวม ดังนั้นฉันต้องการแสดงความคิดเห็นของคุณเกี่ยวกับวิธีแก้ไขปัญหาการโต้เถียงของฉันสำหรับการตรวจสอบข้อยกเว้นที่น่ารำคาญ ด้วยเหตุนี้ฉันจึงสร้างส่วนต่อประสานConsumerCheckException<T>และฟังก์ชั่นยูทิลิตี้rethrow( อัปเดตตามความต้องการของความคิดเห็นของ Doval ) ดังต่อไปนี้: @FunctionalInterface public interface ConsumerCheckException<T>{ void accept(T elem) throws Exception; …

49 java  functional-programming  exceptions  exception-handling  java8 

for (Canvas canvas : list) { } NetBeans แนะนำให้ฉันใช้ "การทำงานตามหน้าที่": list.stream().forEach((canvas) -> { }); แต่นี่คือเหตุผลที่แนะนำ ? ถ้ามีอะไรมันยากที่จะอ่านและเข้าใจ คุณโทรstream()แล้วใช้การแสดงออกแลมบ์ดากับพารามิเตอร์forEach() canvasฉันไม่เห็นว่าเป็นอย่างไรดีกว่าforลูปในตัวอย่างแรก เห็นได้ชัดว่าฉันกำลังพูดถึงสุนทรียภาพเท่านั้น อาจมีข้อได้เปรียบทางเทคนิคที่นี่ที่ฉันหายไป มันคืออะไร? เหตุใดฉันจึงควรใช้วิธีที่สองแทน

39 java  lambda  java8  stream-processing 

สมมติว่าฉันมีกระแสของสิ่งต่าง ๆ และฉันต้องการ "เพิ่มคุณค่า" พวกเขาให้อยู่กลางกระแสฉันสามารถใช้peek()ทำสิ่งนี้ได้เช่น: streamOfThings.peek(this::thingMutator).forEach(this::someConsumer); สมมติว่าการกลายพันธุ์สิ่งต่าง ๆ ณ จุดนี้ในรหัสเป็นการทำงานที่ถูกต้องตัวอย่างเช่นthingMutatorวิธีการอาจตั้งค่าฟิลด์ "lastProcessed" เป็นเวลาปัจจุบัน อย่างไรก็ตามpeek()ในบริบทส่วนใหญ่หมายถึง "มอง แต่ไม่ได้สัมผัส" ใช้peek()เพื่อเปลี่ยนแปลงองค์ประกอบของกระแสข้อมูลที่เป็น antipattern หรือไม่เหมาะสมหรือไม่? แก้ไข: ทางเลือกที่ธรรมดากว่าคือการเปลี่ยนผู้บริโภค: private void thingMutator(Thing thing) { thing.setLastProcessed(System.currentTimeMillis()); } ไปที่ฟังก์ชันที่คืนค่าพารามิเตอร์: private Thing thingMutator(Thing thing) { thing.setLastProcessed(currentTimeMillis()); return thing; } และใช้map()แทน: stream.map(this::thingMutator)... แต่ที่แนะนำรหัสลวก ๆ (คนreturn) และฉันไม่ได้เชื่อว่ามันเป็นที่ชัดเจนเพราะคุณรู้ว่าpeek()ผลตอบแทนที่วัตถุเดียวกัน แต่map()มันไม่ได้ล้างได้อย่างรวดเร็วว่ามันเป็นเดียวกันระดับของวัตถุ นอกจากนี้peek()คุณยังสามารถมีแลมบ์ดาที่กลายพันธุ์ได้ แต่map()คุณต้องสร้างซากรถไฟ เปรียบเทียบ: stream.peek(t -> t.setLastProcessed(currentTimeMillis())).forEach(...) …

36 java  anti-patterns  java8  stream-processing  mutable 

การแนะนำสัญกรณ์แลมบ์ดาใหม่ (ดูตัวอย่างเช่นบทความนี้ ) ใน Java 8 จะต้องใช้การอนุมานบางประเภทหรือไม่? ถ้าเป็นเช่นนั้นระบบประเภทใหม่จะส่งผลกระทบต่อภาษาจาวาโดยรวมอย่างไร

30 java  type-systems  lambda  java8 

นำตัวอย่างโค้ดสองตัวอย่าง: if(optional.isPresent()) { //do your thing } if(variable != null) { //do your thing } เท่าที่ฉันสามารถบอกความแตกต่างที่ชัดเจนที่สุดคือตัวเลือกต้องสร้างวัตถุเพิ่มเติม อย่างไรก็ตามหลายคนเริ่มใช้ตัวเลือกอย่างรวดเร็ว ข้อดีของการใช้ตัวเลือกกับการตรวจสอบค่า Null คืออะไร?

25 java  java8 

เมื่อใช้ Java8 สตรีม api ใหม่เพื่อค้นหาองค์ประกอบเฉพาะในคอลเลกชันฉันเขียนโค้ดดังนี้: String theFirstString = myCollection.stream() .findFirst() .get(); ที่นี่ IntelliJ เตือนว่า get () ถูกเรียกโดยไม่ตรวจสอบ isPresent () ก่อน อย่างไรก็ตามรหัสนี้: String theFirstString = myCollection.iterator().next(); ... ไม่ได้เตือนใด ๆ มีความแตกต่างอย่างลึกซึ้งระหว่างสองเทคนิคนี้หรือไม่ที่ทำให้การสตรีมเข้าหา "อันตราย" มากกว่านี้ในบางด้านนั่นเป็นสิ่งสำคัญที่จะไม่ต้องโทรหารับ () โดยไม่ต้องเรียก isPresent () ก่อน Googling ไปรอบ ๆ ฉันพบบทความที่พูดถึงว่าโปรแกรมเมอร์ไม่ใส่ใจกับตัวเลือก <> และคิดว่าพวกเขาสามารถโทรหา get () ได้ทุกเมื่อ สิ่งที่ฉันชอบที่จะได้รับข้อยกเว้นโยนฉันที่ใกล้ที่สุดกับสถานที่ที่รหัสของฉันเป็นรถซึ่งในกรณีนี้จะเป็นที่ที่ฉันโทรหารับ () เมื่อไม่มีองค์ประกอบที่จะพบ ฉันไม่ต้องการที่จะเขียนเรียงความไร้ประโยชน์เช่น: Optional<String> …

23 java8 

ฉันสงสัยว่าการวัดการครอบคลุมโค้ดตามเงื่อนไขด้วยเครื่องมือปัจจุบันสำหรับ Java นั้นไม่ล้าสมัยหรือไม่นับตั้งแต่ Java 8 ออกมา ด้วย Java 8's OptionalและStreamเราสามารถหลีกเลี่ยงโค้ดย่อย / ลูปได้ซึ่งทำให้ง่ายต่อการได้รับความคุ้มครองตามเงื่อนไขสูงมากโดยไม่ต้องทดสอบพา ธ การประมวลผลที่เป็นไปได้ทั้งหมด ลองเปรียบเทียบโค้ด Java เก่ากับโค้ด Java 8: ก่อน Java 8: public String getName(User user) { if (user != null) { if (user.getName() != null) { return user.getName(); } } return "unknown"; } มี 3 เส้นทางการประมวลผลที่เป็นไปได้ในวิธีการข้างต้น เพื่อให้ได้ความคุ้มครองตามเงื่อนไข 100% เราจำเป็นต้องสร้างการทดสอบ …

19 java  unit-testing  test-coverage  java8 

ในขณะที่การพัฒนา API ของฉันที่ไม่ได้เชื่อมโยงกับรหัสดั้งเดิมใด ๆ ฉันมักจะพบว่าตัวเองเขียนวิธีการที่ Streams หมดจดไปป์ไลน์โดยการรวบรวมผลลัพธ์ ชอบสิ่งนี้: ImmutableSet<T> deriveSomethingMeaningfulFromPrivateState() { return myPrivateThingies.stream() .map(this::ownerOfThing) .map(Owner::socialStatus) .filter(SocialStatus::isHeAFineMatey) .collect(MyCustomCollectors.toImmutableSet()); } ตอนนี้ลูกค้าส่วนใหญ่ของคลาสนี้มักจะต้องการคอลเล็กชัน (ในกรณีนี้คือ ImmutableSet) เพื่อค้นหาองค์ประกอบและวนซ้ำ แต่ลูกค้าบางรายอาจได้รับประโยชน์จากการมีสตรีมดังนั้นพวกเขาจึงสามารถดำเนินการเพิ่มเติมได้ สตรีมโดยไม่จำเป็นต้องรับสตรีมใหม่จากคอลเล็กชัน ดังนั้นการส่งคืนสตรีมจะให้ตัวเลือกที่เหนือกว่าที่พวกเขามีหากพวกเขาเพิ่งมีการสะสม (หลังจากทั้งหมดพวกเขาสามารถcollect()สตรีมได้เสมอ: Stream<T> deriveSomethingMeaningfulFromPrivateState() { return myPrivateThingies.stream() .map(this::ownerOfthing) .map(Owner::socialStatus) .filter(SocialStatus::isHeAFineMatey); // No collect } วิธีการนี้ดึงดูดให้ฉันลองเพราะฉันไม่เห็นข้อบกพร่องใด ๆ ที่อาจเกิดขึ้น อย่างไรก็ตามฉันไม่เคยเห็นวิธีการนี้ในห้องสมุดใด ๆ (อาจเพราะไม่มีห้องสมุดจำนวนมากที่เผยแพร่หลังจากการปรากฏตัวของ Java 8) ดังนั้นฉันกลัวที่จะยอมรับมัน คลาสไลบรารีที่มีอยู่มักจะส่งคืนคอลเล็กชันเมื่อได้รับบางสิ่งจากสถานะส่วนตัว มีบางสิ่งที่ไม่ดีที่อาจเกิดขึ้นได้หรือไม่หากฉันตัดสินใจคืนสตรีมในที่ใดก็ตามที่ตัวเอง pre-Java-8 …

19 java  collections  java8  stream-processing 

โค้ด Scala ต่อไปนี้ใช้งานได้และสามารถส่งผ่านไปยังเมธอด Java ที่ต้องการฟังก์ชัน มีวิธีที่สะอาดกว่านี้หรือไม่? นี่คือการผ่านครั้งแรกของฉัน: val plusOne = new java.util.function.Function[Int,Int] { override def apply(t:Int):Int = t + 1 override def andThen[V](after:function.Function[_ >: Int, _ <: V]): function.Function[Int, V] = ??? override def compose[V](before:function.Function[_ >: V, _ <: Int]): function.Function[V, Int] = ??? } นี่คือรอบที่สองของฉัน - มันใช้ wrapper ทั่วไปสำหรับส่วนต่อประสานฟังก์ชั่น …

18 functional-programming  scala  functions  higher-order-functions  java8 

IntelliJ IDEA แนะนำให้ฉันตอนนี้เพื่อแทนที่ลูปสำหรับแต่ละลูปต่อไปนี้ด้วยการเรียก Java 8 "forEach": for (Object o : objects) { if (o instanceof SomeObject) { doSomething(); } } การโทรที่แนะนำจะเป็นเช่นนี้: objects.stream().filter(o -> o instanceof SomeObject).forEach(o -> doSomething()); เว้นแต่ว่าฉันเข้าใจผิดว่าฟังก์ชันการทำงานพื้นฐานของ Stream ทำงานอย่างไรฉันดูเหมือนว่าการใช้ stream เป็นการดำเนินการ O (2n) ซึ่งตรงข้ามกับการดำเนินการ O (n) สำหรับมาตรฐานสำหรับแต่ละลูป

15 java  performance  java8