JEP 547 Lazy Constants ขยับเป็น Candidate รอบ Preview ที่ 4 — ยังไม่ล็อกเข้า JDK 28

เมื่อวานนี้ (15 ตุลาคม 2026) JEP 547: Lazy Constants (Fourth Preview) ได้ถูกยกระดับจาก Draft ขึ้นมาเป็น Candidate ตามรายงานจาก InfoQ (infoq.com) และหน้า JEP อย่างเป็นทางการ (openjdk.org) โดยจะเป็นการ preview ครั้งที่ 4 ใน JDK 28 โดยไม่มีการเปลี่ยนแปลงใด ๆ จากเวอร์ชันก่อนหน้าใน JDK 25, 26 และ 27 ตามที่ระบุในเอกสาร JEP ชัดเจน

สำหรับคนที่เขียนโค้ด Java ทุกวัน โดยเฉพาะแอปที่ต้องโหลด config, logger, connection pool หรือข้อมูลที่แพงตอน startup เรื่องนี้ช่วยลดเวลาเปิดโปรแกรมได้จริง และยังปลอดภัยกับการใช้งานหลาย thread โดยไม่ต้องเขียนโค้ดซับซ้อนแบบเก่า

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

JEP 547 เปลี่ยนสถานะเป็น Candidate แล้ว (openjdk.org) โดยเสนอให้ preview Lazy Constants เป็นครั้งที่ 4 ใน JDK 28 โดยไม่เปลี่ยน API หรือพฤติกรรมจากเดิมเลย หลังจากเคย preview มาแล้ว 3 รอบใน JDK 25 (JEP 502), JDK 26 (JEP 526) และ JDK 27 (JEP 531) ชื่อเดิมคือ Stable Values หรือ Computed Constants แต่เปลี่ยนมาเป็น Lazy Constants ตั้งแต่ JDK 26 เพื่อให้ตรงกับการใช้งานจริงมากขึ้น (infoq.com)

มันคือ “กล่องเก็บค่าที่เปลี่ยนไม่ได้” ซึ่งสร้างตอนแรกแต่ยังไม่คำนวณค่าจริง จนกว่าจะถูกเรียกใช้ครั้งแรก และรับประกันว่าคำนวณแค่ครั้งเดียวเท่านั้น แม้หลาย thread จะเรียกพร้อมกันก็ตาม ช่วยให้แอป startup เร็วขึ้นเพราะไม่ต้องสร้างของแพง ๆ ทุกตัวตั้งแต่เปิดโปรแกรม (openjdk.org)

ตอนนี้ยังไม่ใช่ของที่จะรวมใน JDK 28 แน่นอน เพราะสถานะยังเป็น Candidate เท่านั้น ตามที่หน้าโครงการ JDK 28 ระบุว่ายังเปิดรับ JEP ที่เสนอเข้ามา (openjdk.org)

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

ถ้าคุณเป็น programmer Java หรือทำงานกับระบบ backend ที่ต้องเปิดแอปทุกเช้า คุณคงเคยเจอปัญหาโปรแกรมช้าเพราะต้องสร้าง logger, อ่านไฟล์ config, เชื่อมต่อฐานข้อมูล หรือสร้าง object ใหญ่ ๆ หลายตัวตั้งแต่ class ถูกโหลด

JEP 547 ช่วยแก้ตรงนี้ได้โดยให้เราเขียนโค้ดแบบ “สร้างเมื่อไหร่ก็ได้” แต่ยังคงความปลอดภัยและเร็วเหมือน final field ทั่วไป สำหรับนักพัฒนาทั่วไป มันหมายถึงแอปที่เปิดเร็วขึ้น, ใช้หน่วยความจำน้อยลงในช่วงแรก, และโอกาสเกิด bug จากการ initialize ผิดพลาดก็น้อยลง

ส่วนเจ้าของธุรกิจเล็ก ๆ ที่มีระบบภายใน หรือนักศึกษาที่เรียน Java มันคือเครื่องมือที่จะทำให้โค้ดสะอาดขึ้น ไม่ต้องพึ่ง pattern เก่า ๆ ที่ซับซ้อนและเสี่ยงต่อ multi-thread อีกต่อไป นอกจากนี้ยังช่วยลดต้นทุนการรันเซิร์ฟเวอร์ระยะยาวเพราะระบบใช้ทรัพยากรน้อยลงตั้งแต่เริ่มต้น

ทำงานยังไง

LazyConstant คือคลาสใน java.lang ที่เก็บค่าที่เปลี่ยนไม่ได้ (immutable) โดยค่าจริงจะถูกสร้างด้วยฟังก์ชัน (lambda) ที่เราส่งเข้าไปตอนสร้าง object เท่านั้น

วิธีใช้หลัก ๆ คือ

• ใช้ LazyConstant.of(() -> คำนวณค่า) เพื่อสร้าง
• เรียก .get() เพื่อเอาค่าออกมา

ถ้ายังไม่เคยสร้าง มันจะเรียกฟังก์ชันนั้นครั้งเดียว เก็บผลลัพธ์ไว้ แล้วคืนค่าให้ทุกครั้งที่เรียกหลังจากนั้น แม้จะมีหลาย thread เรียกพร้อมกัน JVM ก็จัดการให้คำนวณแค่ครั้งเดียวและปลอดภัย (openjdk.org)

มันยังมี factory สำหรับ collection เช่น List.ofLazy(), Map.ofLazy(), Set.ofLazy() ซึ่งจะคำนวณสมาชิกเมื่อถูกเรียกใช้จริง ๆ เท่านั้น ตามที่ปรากฏใน preview API list ของ JDK 28 EA (download.java.net)

ภาพในหัวแบบง่าย ๆ คือ แทนที่จะสร้าง logger หรือ config ตัวใหญ่ตั้งแต่คลาสโหลด เราห่อมันไว้ใน LazyConstant แล้วเรียก .get() ตอนที่ต้องใช้จริงครั้งแรก ครั้งต่อ ๆ ไปก็ได้ของชิ้นเดิมกลับมาทันที (ฟีเจอร์นี้ยังเป็น preview ต้องเปิด --enable-preview ตอนคอมไพล์และรัน)

เปรียบเทียบกับร้านกาแฟตามสั่ง
คิดเหมือนร้านกาแฟที่ไม่ต้มน้ำร้อนรอตั้งแต่เปิดร้านเช้า (เพราะอาจไม่มีลูกค้า) แต่พอมีลูกค้าสั่งลาเต้แก้วแรก มันถึงค่อยต้มน้ำครั้งเดียว เก็บน้ำร้อนไว้ในหม้อ แล้วแก้วต่อ ๆ ไปก็ใช้หม้อเดียวกันทันที ไม่ต้องต้มใหม่ทุกครั้ง และไม่เคยต้มซ้ำสองครั้งพร้อมกัน แม้ลูกค้าสองคนจะสั่งพร้อมกันเป๊ะ ๆ

นี่คือสิ่งที่ LazyConstant ทำกับ object แพง ๆ อย่าง logger, config, database pool หรือ cache มันช่วยให้เราแยกการประกาศ object ออกจากการสร้างจริงได้อย่างสมบูรณ์ โดยที่ JVM ยังมั่นใจได้ว่าค่านั้นจะถูกสร้างแค่ครั้งเดียวและไม่เปลี่ยนแปลงหลังจากนั้น

นอกจากนี้ JEP ยังอธิบายว่ามันช่วยให้เรา compose lazy constants จากกันและกันได้ เช่น lazy constant ตัวหนึ่งอาจขึ้นอยู่กับอีกตัวหนึ่งโดยไม่ต้องสร้างทั้งหมดตั้งแต่แรก ซึ่งเป็นประโยชน์มากสำหรับแอปพลิเคชันขนาดใหญ่ที่มีการพึ่งพากันซับซ้อน

จุดหักมุม: ชื่อเปลี่ยน 3 ครั้งแต่แก่นยังเหมือนเดิม

เดิมทีเรียก Stable Values แล้วเปลี่ยนเป็น Computed Constants ก่อนจะมาเป็น Lazy Constants ใน JDK 26 (openjdk.org) การเปลี่ยนชื่อครั้งใหญ่ใน JEP 526 คือการตัดฟังก์ชันระดับต่ำออกไป เหลือแต่ factory ที่รับ function เพื่อเน้นการใช้งานระดับสูง ไม่ให้คนเข้าใจผิดว่าเป็นเครื่องมือสำหรับเขียนโค้ดระบบ

และใน preview ครั้งที่ 4 นี้ JEP บอกชัดว่า “with no changes” หลังจากปรับครั้งใหญ่ใน JDK 27 ที่เพิ่ม Set.ofLazy() และตัด isInitialized(), orElse() ออกไปแล้ว (openjdk.org) แม้ InfoQ จะรายงานเมื่อวันที่ 12 ตุลาคม แต่ JEP ถูกอัพเดทเมื่อ 14 ตุลาคม ทำให้เราต้องดูทั้งสองแหล่งเพื่อความครบถ้วน (infoq.com)

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

สำหรับธุรกิจที่รัน Java บน server ทุกวัน การลดเวลา startup แม้เพียงไม่กี่วินาทีก็แปลเป็นเงินได้ โดยเฉพาะระบบที่ต้อง restart บ่อย หรือใช้ auto-scaling บน cloud

• ลดการใช้ CPU และ memory ตอนเปิดแอป เพราะไม่ต้องสร้าง object ที่อาจไม่ถูกใช้
• แอปที่เคยใช้ double-checked locking หรือ holder class idiom จะเขียนง่ายและปลอดภัยขึ้น
• JVM สามารถทำ constant folding ได้เหมือน final field หลังจาก initialize แล้ว ทำให้โค้ดเร็วขึ้นจริง ๆ (openjdk.org)

สำหรับทีม IT ขนาดกลางถึงใหญ่ มันช่วยลดค่าใช้จ่ายด้าน server ได้โดยตรง เพราะเครื่องสามารถรับ load ได้เร็วขึ้นและใช้ทรัพยากรน้อยลงในช่วง peak time นอกจากนี้ยังลดความเสี่ยงจาก bug ที่เกิดจากการ initialize ผิดพลาดซึ่งอาจนำไปสู่ downtime และสูญเสียรายได้

ในมุมของนักพัฒนา มันลดเวลา debugging โค้ดเกี่ยวกับ initialization ได้มาก เพราะไม่ต้องกังวลเรื่อง race condition อีกต่อไป

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

• สถานะใน JDK 28: JEP 547 ยังเป็น Candidate เท่านั้น InfoQ บอกว่า “elevated to Candidate status” (infoq.com) แต่หน้า JEP ยังไม่ได้ระบุว่า “Proposed to Target” เหมือน JEP อื่น ๆ ในรอบเดียวกัน จึงยังไม่ยืนยันว่าจะรวมใน JDK 28 จริงหรือไม่ ต้องติดตามต่อ (openjdk.org) หน้าโครงการ JDK 28 เองก็ยังไม่ได้อัพเดทให้เห็นชัดเจน (openjdk.org)
• วันที่อัพเดท: หน้า JEP บอก updated 2026/10/14 (openjdk.org) ขณะที่ InfoQ roundup ออกเมื่อ 12 ตุลาคม ซึ่งอาจหมายถึงข้อมูลใน roundup มาจากสถานะก่อนวันที่ 14 เล็กน้อย
• JDK 28 เองยังอยู่ใน early-access build 19 เมื่อสัปดาห์ก่อนตามที่ InfoQ รายงาน และหน้าโครงการยังอัพเดทล่าสุดเมื่อ 15 ตุลาคม (openjdk.org)

ไม่มีตัวเลขประสิทธิภาพหรือ benchmark ใด ๆ ในเอกสารทั้งสี่แหล่ง จึงยังบอกไม่ได้ว่าช่วยเร็วขึ้นกี่เปอร์เซ็นต์ นอกจากนี้ยังไม่มีข้อมูลราคาหรือกำหนดการปล่อย JDK 28 อย่างเป็นทางการ

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

สำหรับ programmer ทั่วไปและนักศึกษา

1. อ่าน JEP 547 ให้เข้าใจก่อน (openjdk.org)
2. ดาวน์โหลด JDK 28 Early Access แล้วลองใช้ในโปรเจกต์ทดลองด้วย --enable-preview
3. เริ่มเปลี่ยน logger, config loader หรือ singleton แพง ๆ เป็น LazyConstant.of() แทน pattern เก่า
4. ทดสอบ multi-thread ด้วยเครื่องมือเช่น JMH เพื่อดูผลจริงและเปรียบเทียบเวลา startup ก่อนหลัง

สำหรับทีมพัฒนาและ tech lead

1. วางแผน migration จาก double-checked locking และ static holder idiom ไปใช้ LazyConstant
2. อัพเดท coding guideline ของทีมให้รวม preview feature นี้เมื่อถึงเวลา
3. ติดตามสถานะ JEP นี้ในแต่ละ build ของ JDK 28 และทดสอบกับ codebase จริง
4. จัด session ภายในทีมเพื่อแชร์ตัวอย่างการใช้งานและข้อควรระวัง

สำหรับเจ้าของธุรกิจหรือผู้จัดการ

1. ถามทีมพัฒนาว่าปัจจุบันมีปัญหาเรื่องเวลาเปิดแอปหรือไม่
2. สนับสนุนให้ทีมลองใช้เครื่องมือใหม่จาก OpenJDK และจัดสรรเวลาให้
3. ติดตามข่าว JDK 28 ว่าจะ release เมื่อไหร่ (ยังไม่มีกำหนดชัดจากเอกสาร)
4. พิจารณาผลกระทบต่อระบบ production ที่อาจได้รับประโยชน์จาก startup time ที่ดีขึ้น

ผมมองว่า…

ผมมองว่า JEP 547 เป็นการแก้ปัญหาที่นักพัฒนา Java เจอมาตลอด 20 ปี ไม่ใช่การเพิ่ม syntactic sugar อีกตัว แต่คือการให้ “deferred immutability” ที่ปลอดภัยและเร็วจริง ๆ ซึ่งจะทำให้โค้ดสะอาดขึ้นและแอปเร็วขึ้นพร้อมกัน มันช่วยลดความซับซ้อนของโค้ดลงอย่างมากและทำให้ JVM มีโอกาส optimize ได้ดีกว่าเดิม

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

• สถานะของ JEP 547 ว่าจะกลายเป็น Proposed to Target for JDK 28 หรือไม่
• Performance benchmark จาก community หลังจาก build EA ออกมาเพิ่ม
• การเปลี่ยนแปลง (ถ้ามี) ใน preview รอบถัดไป
• ว่า LazyConstant จะถูกใช้ในไลบรารีหลักของ Java เองมากน้อยแค่ไหน
• กำหนดการปล่อย JDK 28 อย่างเป็นทางการจาก OpenJDK

ลองเปิด JDK 28 EA แล้วลองเขียนโค้ดเล่นดูครับ ผมว่ามันสนุกและใช้งานได้จริงมาก

Recap

• อ่าน JEP 547 ที่ https://openjdk.org/jeps/547
• ดาวน์โหลด JDK 28 Early Access build ล่าสุด
• ทดลองใช้ LazyConstant.of() กับ logger หรือ config ในโปรเจกต์ทดลอง
• เปิด compile ด้วย —enable-preview
• ตรวจสอบว่าโค้ด multi-thread ยังปลอดภัยอยู่
• ติดตามข่าว JDK 28 ต่อไปทุกสัปดาห์
• พิจารณา refactor ส่วนที่ startup ช้าในโปรเจกต์จริงเมื่อถึงเวลา
• แชร์ประสบการณ์การใช้งานกับเพื่อนร่วมทีม