Gatherers4j 0.15.0 เพิ่มสถิติใน Java Streams อัปเกรดแล้วต้องเช็กอะไร

ประมาณ 2.1 พันล้านรายการ คือจุดที่บั๊กเดิมของ movingMin() และ movingMax() อาจนำค่าที่ผิดออกจากช่วงคำนวณ โดย Gatherers4j 0.15.0 แก้ปัญหานี้พร้อมเพิ่มเครื่องมือสรุปสถิติระหว่างประมวลผลข้อมูลใน Java ครับ (GitHub Releases) สำหรับคนที่รอรายงานยอดขายหรือใช้ตัวเลขในหน้าสรุปธุรกิจ เรื่องที่ควรสนใจจึงมีทั้งความสามารถใหม่และการตรวจว่าหลังอัปเกรด ตัวเลขยังตรงกับความหมายที่ต้องการหรือไม่

InfoQ รายงานรุ่นนี้ในข่าวรวม Java วันที่ 19 ตุลาคม 2026 โดยชูการสรุปสถิติแบบช่วงล่าสุด แบบสะสม และค่าเฉลี่ยเคลื่อนที่ถ่วงน้ำหนัก แต่รายละเอียดในบันทึกรุ่นยังมีการเปลี่ยนชื่อเมธอดและพฤติกรรมการคำนวณด้วย เมธอดในที่นี้คือคำสั่งที่โปรแกรมเรียกใช้งานครับ (InfoQ, GitHub Releases)

สรุป 30 วินาที: เกิดอะไรขึ้น

Gatherers4j เป็นไลบรารี หรือชุดเครื่องมือที่นักพัฒนานำไปใช้ในโปรแกรม เพื่อเพิ่มขั้นตอนประมวลผลระหว่างทางให้ Java Streams ซึ่งเป็นวิธีจัดการข้อมูลเป็นลำดับ รุ่น 0.15.0 เพิ่ม movingStatistics(), movingStatisticsBy(), runningStatistics() และ runningStatisticsBy() โดยส่งผลสรุปสถิติออกมาสำหรับข้อมูลแต่ละรายการ (เอกสาร Gatherers4j, GitHub Releases)

ผลนั้นอยู่ใน StatisticalSummary ซึ่งเป็น record หรือโครงสร้างเก็บข้อมูลชุดหนึ่ง มีจำนวนรายการ ผลรวม ค่าเฉลี่ย ค่าต่ำสุด ค่าสูงสุด รวมถึงความแปรปรวนและส่วนเบี่ยงเบนมาตรฐานทั้งแบบประชากรและแบบตัวอย่าง สองคำหลังช่วยอธิบายว่าค่ากระจายห่างจากค่าเฉลี่ยมากเพียงใด ส่วนประชากรหมายถึงข้อมูลทั้งหมดที่สนใจ และตัวอย่างหมายถึงข้อมูลบางส่วนที่ใช้ศึกษาแทนทั้งหมด (GitHub Releases)

อีกรายการสำคัญคือ movingWeightedMean() กับ movingWeightedMeanBy() สำหรับค่าเฉลี่ยเคลื่อนที่ถ่วงน้ำหนัก รองรับน้ำหนักแบบเชิงเส้นและน้ำหนักที่ผู้พัฒนากำหนดเอง โดยเรียงน้ำหนักจากข้อมูลเก่าสุดไปใหม่สุด และก่อนวางแผนอัปเกรดควรทราบว่าโครงการขยับจาก Java 24 เป็น Java 25 ตั้งแต่รุ่น 0.12.0 แล้ว (GitHub Releases)

ทำไมเรื่องนี้เกี่ยวกับคุณ

ถ้าคุณเป็นเจ้าของกิจการหรือพนักงานที่ใช้รายงาน ประเด็นไม่ได้อยู่ที่จำชื่อคำสั่งได้กี่ตัว แต่อยู่ที่ตัวเลขบนหน้าจอกำลังตอบเรื่องไหน ลองสมมติว่าร้านกาแฟอยากเห็นค่าเฉลี่ยยอดขายรายวันในช่วง 7 วันล่าสุด เพื่อดูภาพระยะใกล้ ขณะเดียวกันก็อยากเห็นยอดสะสมตั้งแต่ต้นเดือนเพื่อวางแผนรายจ่าย ทั้งสองอย่างใช้ข้อมูลเดียวกันได้ แต่ควรกำหนดช่วงคำนวณให้ชัดตั้งแต่แรก

ตัวอย่างร้านกาแฟและช่วง 7 วันเป็นโจทย์สมมติสำหรับอธิบาย ไม่ใช่ข้อมูลธุรกิจที่แหล่งข่าวสำรวจ ความเกี่ยวข้องกับข่าวคือรุ่นนี้มีเครื่องมือสถิติทั้งกลุ่ม moving และ running ให้ทีมพัฒนาเลือกใช้ตามโจทย์ (GitHub Releases) ผมแนะนำให้คนสั่งรายงานเขียนความหมายไว้ข้างชื่อช่อง เช่น “ค่าเฉลี่ยช่วงล่าสุด” หรือ “ยอดสะสมตั้งแต่เริ่มช่วงรายงาน” จะได้ตรวจงานกับทีมพัฒนาโดยพูดเรื่องเดียวกัน

สำหรับนักพัฒนา สิ่งที่ควรระวังคือรุ่นนี้เปลี่ยนทั้งหน้าตาคำสั่งที่โปรแกรมเรียกและรายละเอียดการปัดเศษ ตัวเลขท้ายผลลัพธ์จึงอาจต่างจาก 0.14.0 แม้ข้อมูลต้นทางเหมือนเดิม โดยเฉพาะงานที่ใช้ BigDecimal ซึ่งเป็นชนิดตัวเลขทศนิยมที่ควบคุมความละเอียดในการคำนวณได้ (GitHub Releases) ถ้ารายงานของคุณมีเกณฑ์ตรวจเทียบผลแบบตรงทุกหลัก ควรให้ความต่างนี้อยู่ในรายการตรวจรับด้วย

ทำงานยังไง

เอกสารโครงการอธิบายว่า Java มี Streams มาตั้งแต่ Java 8 และมี Collectors สำหรับเขียนการประมวลผลปลายทางอยู่แล้ว ส่วน Gatherers เปิดให้เพิ่มการประมวลผลระหว่างทางได้สะดวกขึ้น จึงช่วยต่อขั้นตอนที่ต้องการเข้าไปในลำดับงานก่อนถึงผลสุดท้ายได้ บทความนี้เรียกสิ่งนี้ว่า Stream Gatherers ใน JDK รุ่นใหม่ เพราะแหล่งข้อมูลที่ให้มาไม่ได้ระบุหมายเลข JEP หรือยืนยันรุ่นที่ฟีเจอร์เสร็จสมบูรณ์ (เอกสาร Gatherers4j)

ลองนึกถึงสมุดจดยอดขายร้านกาแฟครับ แบบ moving คือเปิดดูเฉพาะหน้าที่อยู่ในช่วงล่าสุดที่กำหนด เมื่อมีวันใหม่เข้ามา วันที่เก่าสุดนอกช่วงก็เลิกมีส่วนในสถิตินั้น ส่วนแบบ running คือคำนวณต่อจากรายการแรกที่เริ่มนับมาจนถึงรายการปัจจุบัน ถ้าจะใช้แทน “ทั้งเดือน” ทีมต้องกำหนดให้ชุดข้อมูลเริ่มต้นตรงต้นเดือนด้วย ชื่อ running เพียงอย่างเดียวไม่ใช่ข้อกำหนดรอบบัญชี ตัวอย่างนี้ช่วยแยกความหมายของเครื่องมือ moving และ running ที่บันทึกรุ่นระบุไว้ (GitHub Releases)

เมื่อเลือกกลุ่ม Statistics ผลที่ได้ไม่จำเป็นต้องรอเป็นสรุปก้อนเดียวเมื่ออ่านข้อมูลครบ เพราะบันทึกรุ่นระบุว่าส่ง StatisticalSummary สำหรับแต่ละรายการ จึงมีผลสรุปตามจังหวะที่ข้อมูลถูกประมวลผล ทั้งจำนวน ผลรวม ค่าเฉลี่ย และค่าการกระจายอยู่ในโครงสร้างเดียวกัน (GitHub Releases) ในเชิงออกแบบรายงาน เราจึงควรถามต่อว่าต้องการเก็บผลทุกจังหวะหรือเลือกแสดงเฉพาะจุดที่จำเป็น เพื่อไม่ให้ความต้องการหน้าจอคลุมเครือ

ส่วนค่าเฉลี่ยถ่วงน้ำหนักคือการกำหนดให้แต่ละรายการมีส่วนต่อค่าเฉลี่ยไม่เท่ากัน รุ่นนี้ให้ใช้แบบเชิงเส้นหรือกำหนดชุดน้ำหนักเอง และระบุชัดว่าลำดับคือเก่าสุดไปใหม่สุด (GitHub Releases) หากนำแนวคิดนี้ไปทดลองกับราคาหุ้นหรือทอง ผมแนะนำให้ตรวจว่าคุณตั้งใจให้น้ำหนักกับช่วงเวลาใด และลำดับข้อมูลตรงกับลำดับน้ำหนักหรือยัง ตัวอย่างนี้เป็นโจทย์การคำนวณ ไม่ใช่คำแนะนำซื้อขายหรือคำรับรองว่าจะทำนายราคาได้

จุดสังเกต: ผลช่วงแรกและทศนิยมท้ายอาจเปลี่ยนความหมายรายงาน

รายละเอียดที่มองข้ามง่ายคือกลุ่ม moving มีประวัติเปลี่ยนพฤติกรรมตั้งแต่รุ่น 0.13.0 ให้แสดงผลที่คำนวณได้ตามปกติ แม้ยังมีข้อมูลไม่ครบช่วงย้อนหลัง หากต้องการงดผลช่วงที่ยังไม่ครบ ใช้ excludePartialValues() แทนแนวทางเดิมที่ต้องเปิดด้วย includePartialValues() เรื่องนี้เป็นการเปลี่ยนจากรุ่นก่อน ไม่ควรนับเป็นของใหม่ใน 0.15.0 (GitHub Releases)

ถ้าตั้งใจแสดงค่าเฉลี่ย 7 วันในโจทย์สมมติข้างต้น ผมแนะนำให้ตกลงว่าในวันแรก ๆ จะยอมแสดงค่าเฉลี่ยจากข้อมูลเท่าที่มีหรือรอให้ครบช่วง และให้หน้ารายงานสื่อความหมายเดียวกัน การมีตัวเลขขึ้นมาได้กับการมีข้อมูลครบช่วงเป็นคนละเงื่อนไขที่ควรตรวจรับครับ

สำหรับ 0.15.0 การคำนวณด้วย BigDecimal จะปัดข้อมูลเข้าแต่ละรายการตาม MathContext หรือการตั้งค่าความละเอียดและการปัดเศษ จากนั้นสะสมผลรวม ค่าเฉลี่ย และส่วนเบี่ยงเบนมาตรฐานอย่างแม่นตรงโดยไม่ปัดซ้ำทุกขั้นเหมือนเดิม บันทึกรุ่นจึงเตือนว่าหลักท้ายอาจต่างจาก 0.14.0 (GitHub Releases)

แต่กลุ่ม exponentialMovingAverageWithAlpha(), exponentialMovingAverageWithPeriod() และแบบ By เปลี่ยนไปปัดเศษทุกขั้น จากเดิมที่ไม่ปัดเลยจนข้อมูลยาวทำให้จำนวนหลักเพิ่มขึ้นเรื่อย ๆ และทำงานช้าลง กลุ่มนี้เป็นค่าเฉลี่ยเคลื่อนที่อีกวิธีหนึ่ง จึงต้องอ่านแยกจากพฤติกรรมการสะสมของกลุ่มก่อนหน้า (GitHub Releases)

เรื่องเงิน / ผลกระทบ

สำหรับงานธุรกิจ ผมเสนอให้มองต้นทุนเป็นเวลาตรวจแก้โปรแกรมและตรวจรับรายงาน เพราะบันทึกรุ่นระบุการเปลี่ยนที่ทำให้โค้ดเดิมต้องปรับ หรือ breaking changes หลายรายการ ดังนั้นเลขรุ่นที่ขยับเพียงเล็กน้อยไม่ควรเป็นเหตุผลเดียวในการประเมินงานอัปเกรด (GitHub Releases)

บั๊กที่แก้ยังเกี่ยวกับความน่าเชื่อถือของผลคำนวณด้วย sampleFixedSize() เคยสุ่มด้วยโอกาสไม่เท่ากัน โดยรายการช่วงต้นที่มีจำนวนเท่าขนาดตัวอย่างถูกเลือกน้อยเกินไป ส่วนรายการภายหลังถูกเลือกมากเกินไป รุ่นนี้แก้ปัญหาดังกล่าวแล้ว (GitHub Releases) หากทีมใช้การสุ่มเลือกข้อมูลไปตรวจคุณภาพ ผมแนะนำให้ทบทวนการตรวจผลส่วนนี้ด้วย เพราะคำว่า “สุ่ม” บนหน้าจอไม่ใช่หลักฐานว่าการสุ่มในโปรแกรมทำงานถูกต้อง

รุ่นนี้ยังแก้การสะสมข้อผิดพลาดจากการปัดเศษในผลคูณแบบเคลื่อนที่และค่าเฉลี่ยเรขาคณิตเมื่อข้อมูลยาว รวมถึงกรณีค่าเฉลี่ยเรขาคณิตผิดหรือเกิดข้อผิดพลาดเมื่อผลคูณเกินช่วงที่ double ชนิดตัวเลขทศนิยมอีกแบบหนึ่งรองรับ และแก้ movingMin() กับ movingMax() ที่ช้าลงเมื่อช่วงคำนวณใหญ่และข้อมูลเพิ่มหรือลดต่อเนื่อง (GitHub Releases)

เอกสารระบุว่าโครงการใช้สัญญาอนุญาต Apache 2.0 และมีไลบรารีที่ต้องใช้ร่วมโดยตรงเพียง JSpecify ซึ่งช่วยเครื่องมือตรวจโค้ดพิจารณาว่าค่าใดอาจเป็น null หรือไม่มีค่าได้ ส่วนรุ่นนี้อัปเดต JSpecify จาก 1.0.0 เป็น 1.0.1 (เอกสาร Gatherers4j, GitHub Releases) แหล่งข้อมูลไม่ได้ให้ตัวเลขต้นทุนย้ายระบบ ผลประหยัดเวลา หรือความเร็วที่เพิ่มขึ้นเป็นเปอร์เซ็นต์ จึงยังตีเป็นยอดเงินให้ธุรกิจในไทยไม่ได้

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

แหล่งข้อมูลที่ให้มาไม่มีข้อขัดแย้งชัดเจนเกี่ยวกับความสามารถหลักของรุ่นนี้ InfoQ สรุปเรื่องสถิติและค่าเฉลี่ยถ่วงน้ำหนัก ส่วน GitHub แจกแจงรายละเอียดเพิ่มเติม ความสั้นของข่าวรวมจึงไม่ควรถูกตีความว่าการเปลี่ยนพฤติกรรมอื่นไม่มีอยู่ (InfoQ, GitHub Releases)

เรื่องวันที่ควรแยกให้ชัดว่า InfoQ ลงวันที่ 19 ตุลาคม 2026 แต่ชื่อข่าวอ้างถึงรอบข่าววันที่ 12 ตุลาคม ส่วนข้อมูลกำกับแหล่ง GitHub ที่ได้รับระบุวันที่ 11 ตุลาคม 2026 และเนื้อหารายการ v0.15.0 ที่ให้มาไม่มีเวลาประกาศแยกเฉพาะรุ่น จึงไม่ควรสรุปว่าวันลงข่าว InfoQ เป็นวันปล่อยรุ่น หรือแต่งเวลาเปิดตัวเป็นเวลาไทย (InfoQ, GitHub Releases)

ข้อกำหนด Java ที่ใช้วางแผนได้มาจากบันทึกรุ่น 0.12.0 ซึ่งระบุว่าขยับเป็น Java 25 จาก Java 24 ขณะที่รายการ 0.15.0 ไม่ได้ประกาศเปลี่ยนข้อกำหนดนี้เพิ่มเติม ทีมจึงควรวางแผนใช้ JDK 25 ซึ่งเป็นชุดเครื่องมือสำหรับพัฒนา Java ตามประวัติโครงการ และตรวจสภาพแวดล้อมจริงก่อนอัปเกรด ไม่ควรอนุมานว่า Java รุ่นที่รองรับแนวคิด Gatherers จะใช้ไลบรารีรุ่นนี้ได้เสมอ (GitHub Releases)

แหล่งข้อมูลยังไม่แจกแจงรูปแบบเรียกใช้ทุกเมธอด กรณีขอบทั้งหมด หรือผลทดสอบประสิทธิภาพเชิงตัวเลข บทความนี้จึงไม่ให้โค้ดที่อ้างว่าคัดลอกไปใช้ได้ทันที และยังไม่มีข้อมูลว่าองค์กรไทยแห่งใดใช้งานหรือได้รับผลจากบั๊กเหล่านี้ครับ

แล้วเราควรทำอะไร

นักพัฒนา backend — ผู้ดูแลระบบหลังบ้าน

1. ตรวจรุ่น JDK ในเครื่องพัฒนา เครื่องทดสอบ และเครื่องใช้งานจริงให้สอดคล้องกัน โดยใช้การเปลี่ยนเป็น Java 25 ตั้งแต่ 0.12.0 เป็นฐานวางแผน แล้วตรวจระบบจริงก่อนขยับไลบรารี (GitHub Releases)
2. ค้นหาการเรียกชื่อเดิมและปรับให้ตรงรุ่นใหม่ simpleMovingAverage(), simpleMovingAverageBy(), simpleRunningAverage() และ simpleRunningAverageBy() เปลี่ยนเป็น movingMean(), movingMeanBy(), runningMean() และ runningMeanBy() ตามลำดับ (GitHub Releases)
3. ตรวจการคำนวณส่วนเบี่ยงเบนมาตรฐานแบบสะสม เพราะ runningPopulationStandardDeviation(), runningSampleStandardDeviation() และแบบ By ถูกแทนด้วย runningStandardDeviation(Dataset) และ runningStandardDeviationBy(Dataset, Function) โดยมี Dataset ให้เลือก Population หรือ Sample (GitHub Releases)
4. ตรวจโค้ดที่อ้างชนิดผลคืนโดยตรง กลุ่ม BigDecimal เปลี่ยนไปคืน BigDecimalMovingStatGatherer หรือ BigDecimalRunningStatGatherer และเอาคลาสสาธารณะเดิมออก รวมถึง BigDecimalGatherer, BigDecimalSumGatherer และ BigDecimalMedianGatherer บันทึกรุ่นระบุว่าโค้ดที่เพียงเรียกเมธอดสร้างจาก Gatherers4j ไม่ได้รับผลจากการเปลี่ยนชนิดนี้ แต่ยังต้องตรวจการเปลี่ยนอื่นแยกต่างหาก (GitHub Releases)
5. เปลี่ยนจุดที่เรียก SamplePercentageGatherers.poisson() ซึ่งถูกถอดออก ให้ใช้ Gatherers4j.samplePercentage() ตามบันทึกรุ่น ก่อนนำขึ้นระบบจริงให้คอมไพล์และตรวจงานที่เรียกใช้จริงครบถ้วน (GitHub Releases)

นักพัฒนาข้อมูลและรายงาน

1. เขียนนิยามแต่ละช่องให้ชัดว่าจะใช้ช่วงล่าสุดหรือสะสมจากจุดเริ่มต้น แล้วตรวจผลช่วงที่ข้อมูลยังไม่ครบหน้าต่างย้อนหลังด้วย เพราะกลุ่ม moving แสดงผลช่วงไม่ครบเป็นค่าเริ่มต้นมาตั้งแต่ 0.13.0 (GitHub Releases)
2. เตรียมข้อมูลตัวอย่างเดิมเปรียบเทียบก่อนและหลังอัปเกรด พร้อมอธิบายหลักทศนิยมที่ยอมรับได้ โดยอ้างการเปลี่ยนการปัดเศษของ BigDecimal และค่าเฉลี่ยเคลื่อนที่แบบ exponential แยกกัน (GitHub Releases)
3. ตรวจจำนวนผลลัพธ์ช่วงต้นด้วย ส่วนเบี่ยงเบนมาตรฐานแบบตัวอย่างจะไม่ส่งผลสำหรับรายการแรก จากเดิมที่ runningSampleStandardDeviation() ส่ง 0 การจับคู่ผลลัพธ์กับแถวข้อมูลจึงเป็นสิ่งที่ผมแนะนำให้ตรวจเป็นพิเศษ (GitHub Releases)
4. ตรวจข้อมูลที่เป็น NaN หรือค่าที่ไม่ใช่ตัวเลขที่ใช้คำนวณได้ เพราะ samplePercentage() และ exponentialMovingAverageWithAlpha() รวมถึงแบบ By ของรายการหลัง จะปฏิเสธค่านี้แล้ว และ withMathContext() ปฏิเสธความละเอียด 0 เช่น MathContext.UNLIMITED ด้วย (GitHub Releases)

นักเรียนและนักศึกษาที่กำลังเรียน Streams

1. เริ่มจากแยกการประมวลผลระหว่างทางออกจากการสรุปปลายทางตามคำอธิบายในเอกสาร แล้วจึงเรียนว่า Gatherers4j เพิ่มขั้นตอนสำเร็จรูปให้เลือกอย่างไร (เอกสาร Gatherers4j)
2. ลองใช้ชุดยอดขายสมมติสั้น ๆ คิดผลด้วยมือก่อน แล้วระบุให้ได้ว่าต้องการค่าเฉลี่ยช่วงล่าสุดหรือค่าเฉลี่ยสะสม การรู้คำตอบที่คาดไว้จะช่วยให้ตรวจงานตัวเองได้โดยไม่ต้องจำชื่อคำสั่งทุกตัว
3. ตรวจชื่อเมธอดและรุ่นไลบรารีของตัวอย่างที่อ่าน เพราะชื่อค่าเฉลี่ยเดิมถูกเปลี่ยนใน 0.15.0 และรุ่น 0.12.0 ขยับฐานเป็น Java 25 แล้ว หากเจอตัวอย่างเก่า ควรเทียบกับบันทึกรุ่นก่อนนำไปทดลอง (GitHub Releases)

ผมมองว่า…

ผมมองว่า คุณค่าของรุ่นนี้ไม่ใช่จำนวนคำสั่งที่เพิ่มขึ้น แต่คือโอกาสทำให้ทีมพูดเรื่องความหมายของตัวเลขได้ตรงกัน นี่เป็นความเห็นของผมครับ การมีทั้งสถิติช่วงล่าสุด สถิติสะสม และผลสรุปหลายค่าในชุดเดียว ช่วยให้ตั้งโจทย์รายงานได้ชัดขึ้น แต่คนออกแบบยังต้องตัดสินใจเรื่องจุดเริ่มนับ ช่วงข้อมูล น้ำหนัก และการปัดเศษเอง

ผมอยากให้ทีมเผื่อเวลาตรวจการย้ายรุ่นพอ ๆ กับเวลาลองของใหม่ โดยเฉพาะรายงานที่คนอื่นนำไปตัดสินใจเรื่องเงิน ถ้าผลต่างเฉพาะหลักท้ายเพราะวิธีปัดเศษเปลี่ยน ก็ควรอธิบายได้ว่าต่างเพราะอะไร ถ้าเลือกช่วงคำนวณผิด แม้โปรแกรมทำงานผ่านก็ยังตอบผิดเรื่องได้ รายงานมีทศนิยมยาวขึ้นไม่ได้แปลว่าประชุมจะสั้นลงครับ

ปิดท้าย: สิ่งที่ต้องจับตา

จุดที่ควรติดตามคือรายละเอียดการใช้งานและพฤติกรรมของรุ่นที่ทีมเลือกจริง ทั้ง StatisticalSummary การถ่วงน้ำหนัก และการเปลี่ยนที่กระทบโค้ดเดิม โดยใช้บันทึกรุ่นเป็นรายการตรวจร่วมกับเอกสารโครงการ ซึ่งจัดเครื่องมือไว้ทั้งด้านลำดับข้อมูล การคัดเลือก การจัดกลุ่ม การคำนวณ และการตรวจเงื่อนไข (GitHub Releases, เอกสาร Gatherers4j)

สำหรับคนใช้รายงาน ผมแนะนำให้ขอดูตัวอย่างผลก่อนและหลังปรับรุ่น พร้อมคำอธิบายช่วงคำนวณและหลักทศนิยมที่เปลี่ยน ส่วนทีมพัฒนาควรบันทึกว่าตรวจกรณีใดไปแล้ว เพื่อให้การตรวจรับอิงกับความหมายของข้อมูล ไม่ได้จบเพียงเห็นว่าโปรแกรมเปิดใช้งานได้

Recap

• ตกลงให้ชัดว่ารายงานต้องการสถิติช่วงล่าสุดหรือสะสมตั้งแต่จุดเริ่มต้น
• ตรวจฐาน Java 25 จากประวัติรุ่น และเช็ก JDK ของระบบจริงก่อนอัปเกรด (GitHub Releases)
• ตรวจชื่อเมธอดค่าเฉลี่ยและส่วนเบี่ยงเบนมาตรฐานที่เปลี่ยนใน 0.15.0 (GitHub Releases)
• ทบทวนโค้ดที่อ้างคลาส BigDecimal เดิมและคำสั่งสุ่มที่ถูกถอดออก (GitHub Releases)
• เปรียบเทียบผลการปัดเศษและตรวจผลช่วงข้อมูลแรกที่ยังไม่ครบช่วง (GitHub Releases)
• ตรวจลำดับน้ำหนักของค่าเฉลี่ยถ่วงน้ำหนักให้เรียงเก่าสุดไปใหม่สุด (GitHub Releases)
• ทดสอบงานที่ใช้การสุ่ม ค่าต่ำสุด ค่าสูงสุด หรือข้อมูลยาว ซึ่งมีการแก้บั๊กในรุ่นนี้ (GitHub Releases)
• ให้ผู้ใช้รายงานตรวจความหมายของตัวเลขพร้อมทีมพัฒนาก่อนใช้งานจริง