Java 25 / JDK 25 เปิดตัวอย่างเป็นทางการ

 (openjdk.org)
6 คะแนน โดย GN⁺ 2025-09-17 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • Java 25 และอิมพลีเมนเทชันอ้างอิง JDK 25 เปิดตัวอย่างเป็นทางการแล้ว
  • เวอร์ชันนี้มาพร้อมฟีเจอร์ใหม่จาก 18 JEP (Java Enhancement Proposal)
  • มีการเปลี่ยนแปลงสำคัญ เช่น การยกเลิกพอร์ต x86 32 บิต, Scoped Values, Structured Concurrency และการปรับปรุง Primitive Types

Java 25 / JDK 25: เปิดตัวอย่างเป็นทางการ

  • JDK 25 หรืออิมพลีเมนเทชันอ้างอิงของ Java 25 ได้เปิดตัวอย่างเป็นทางการในเวอร์ชัน พร้อมแจกจ่ายเพื่อใช้งานจริง
  • เมื่อวันที่ 15 สิงหาคม 2025 ได้มีการออกรีลีสแคนดิเดตตัวที่สองคือ build 36 และหลังจากนั้น ไม่มีรายงานบั๊กระดับร้ายแรง (P1)
  • build 36 คือเวอร์ชัน GA (General Availability) สุดท้าย และ สามารถใช้งานในสภาพแวดล้อมโปรดักชันได้
  • OpenJDK build ภายใต้ไลเซนส์ GPL นั้น Oracle เป็นผู้จัดให้ใช้อย่างเป็นทางการ และเวอร์ชัน build จากผู้ให้บริการรายอื่นอีกหลายรายก็มีกำหนดจะเผยแพร่ในเร็ว ๆ นี้

ลิงก์ดาวน์โหลด OpenJDK อย่างเป็นทางการ

ฟีเจอร์และการปรับปรุงหลัก

รีลีสนี้ประกอบด้วย 18 JEP (Java Enhancement Proposal)

  • 470: การเข้ารหัสอ็อบเจ็กต์เข้ารหัสลับแบบอิง PEM (พรีวิว)
  • 502: Stable Values (พรีวิว)
  • 503: การยกเลิกพอร์ต x86 32 บิต
  • 505: Structured Concurrency (พรีวิวครั้งที่ 5)
  • 506: Scoped Values
  • 507: รองรับ Primitive Types ใน pattern, instanceof และ switch (พรีวิวครั้งที่ 3)
  • 508: Vector API (เวอร์ชันอินคิวเบเตอร์ครั้งที่ 10)
  • 509: JFR CPU time profiling (ฟีเจอร์ทดลอง)
  • 510: Key Derivation Function API
  • 511: คำประกาศ Module Import
  • 512: Compact Source Files และ instance main methods
  • 513: Flexible Constructor Bodies
  • 514: การปรับแต่ง command line แบบ Ahead-of-Time
  • 515: การทำ method profiling แบบ Ahead-of-Time
  • 518: JFR cooperative sampling
  • 519: Compact Object Headers
  • 520: JFR method timing และ tracing
  • 521: Generational Shenandoah

นอกจาก JEP ข้างต้นแล้ว รีลีสนี้ยังรวมถึง การปรับปรุงฟีเจอร์ย่อยอีกหลายร้อยรายการ และ การแก้ไขบั๊กอีกหลายพันรายการ

รายละเอียดรีลีสเพิ่มเติมและข้อมูลเชิงลึกของแต่ละ JEP สามารถดูได้ที่
หน้าโครงการ OpenJDK JDK 25

บทความที่เกี่ยวข้อง

3 ความคิดเห็น

 
ahwjdekf 2025-09-18

ขอทานเร่ที่เคยมาปีก่อนยังไม่ตายก็กลับมาอีกแล้ว เอ้อระเหยลอยชายเข้ามาอีก .. ทำไมนายถึงโผล่มาอีกเรื่อยเลย?
 
click 2025-09-18

ฟีเจอร์นี้เข้ามาตั้งแต่ JDK 24 แล้ว แต่เนื่องจาก Java มักมีแนวโน้มถูกใช้งานเฉพาะรุ่น LTS เป็นหลัก จึงน่าจับตาเช่นกันว่า JEP 491: Synchronize Virtual Threads without Pinning ทำให้เมื่อใช้คีย์เวิร์ด synchronized จะไม่เกิดอาการ pinning ของ virtual thread อีกต่อไป
ก่อนหน้านี้ใน real-world benchmark ของ virtual thread ก็มักมีหลายกรณีที่ช้ากว่า และส่วนใหญ่สาเหตุมักมาจาก pinning
 
GN⁺ 2025-09-17
ความเห็นจาก Hacker News
  • ผมคิดว่าควรมีโปรแกรมใหม่ ๆ อีกมากที่เขียนด้วย Java หรือบน JVM เหตุผลที่ทำให้ Java เสื่อมความนิยมในอดีตตอนนี้แทบไม่เหลือแล้ว และตอนนี้มันเป็น ecosystem ที่เสถียรและเติบโตเต็มที่มาก โปรแกรม Clojure ที่ผมเขียนไว้เมื่อ 10 ปีก่อนก็ยังรันได้ดีไม่มีปัญหา ขณะที่โปรแกรมที่เขียนด้วย TypeScript กลับต้องคอยบำรุงรักษาและอัปเดตภายในเวลาแค่ 6 เดือน
    • เรื่องที่กังวลมากคือ Oracle มันน่ารำคาญที่เวลาใช้ Java ต้องคอยระวังไม่ให้ละเมิด EULA ของ Oracle ใช้ openjdk ก็น่าจะโอเค แต่บางทีก็อยากใช้ภาษาอื่นไปเลยแบบไม่ต้องกังวล C# ก็ให้สภาพแวดล้อมคล้ายกับ java โดยไม่ต้องกังวลเรื่อง Oracle แทนที่จะเสียเวลาเรียนรู้วิธีใช้ Java ให้ปลอดภัย ผมคิดว่าเลือกภาษาอื่นไปเลยดีกว่า เพราะ Java ก็ไม่ได้จำเป็นถึงขั้นไม่มีทางเลือกอื่น
    • Java ยังได้รับความนิยมอย่างมากและถูกใช้อย่างแพร่หลายในระบบ backend ขนาดใหญ่ ผมแปลกใจที่ดูเหมือนจะมีคนที่ทำงานกับระบบแบบนั้นในที่นี่ไม่มากนัก จากประสบการณ์ของผม Java เป็นสิ่งที่เจอแทบตลอด
    • แอบหวังอยู่ลึก ๆ ว่า Kotlin กับ Compose จะช่วยชุบชีวิตแอปเดสก์ท็อปบน JVM กลับมาอีกครั้ง
    • ผมคิดว่าจุดที่ยังเสี่ยงต่อการยอมรับ Java ต่อไปคือวัฒนธรรมที่เกี่ยวข้อง นักพัฒนา Java รุ่นเก่าและโปรแกรม Java เดิม ๆ มักเขียนแบบยืดยาวเกินจำเป็น ทั้งที่ตัวภาษาเองมีฟีเจอร์ที่ทำให้เขียนกระชับได้เหมือนภาษา modern อื่น ๆ แล้ว ถึงอย่างนั้น Java ก็ยังใหญ่พอที่จะเปลี่ยนแปลงได้
    • ผมสงสัยว่าโปรแกรม Clojure ที่เขียนเมื่อ 10 ปีก่อนยังรันได้ดีนั้นเป็นเพราะ JVM หรือเพราะแนวทางเฉพาะของ Clojure กันแน่ ผมเองก็มีประสบการณ์คล้ายกันกับโปรเจกต์ ClojureScript สคริปต์ nbb เก่า ๆ ก็ยังทำงานได้ดีทันทีแทบไม่มีปัญหาเลย (บางครั้งแค่ต้องปรับ npm dependency นิดหน่อย) ขณะที่ฝั่ง Python บางทีผมเสียเวลาครึ่งวันไปกับปัญหา dependency และการจัดการ venv
  • Java เป็นฐานทางเทคนิคที่แข็งแกร่งอย่างน่าทึ่งมาอย่างยาวนาน อาจไม่ใช่ภาษาที่น่าดึงดูดที่สุด แต่แสดงให้เห็นถึงความเสถียรอยู่เสมอ แอปที่สร้างด้วย Java 1.4 ยังทำงานได้ดีบน Java 21 LTS และผมมีแผนจะอัปเกรดเป็น Java 25 เร็ว ๆ นี้ Java สุดยอดมาก
    • ผมสงสัยว่าถ้าไม่มีเครื่องมืออันยอดเยี่ยมของ JetBrains กับโปรแกรมสำหรับนักศึกษาที่ฉลาดมาก ๆ Java จะมาอยู่จุดไหนในวันนี้
    • ถึงจะห่างไกลกันอยู่พอสมควร แต่ผมยังจำแอป Gmail ที่เขียนด้วย Java ซึ่งรันบนมือถือ Symbian แบบจอสัมผัสของผมในปี 2009 ได้อยู่เลย มันน่ารักมากและก็ใช้งานได้ดีด้วย
    • จากประสบการณ์ของผม ผมไม่เห็นด้วยทั้งหมด ทุกครั้งที่บริษัทหลายแห่งอัปเกรดเวอร์ชัน JVM มักจะมีปัญหาใหญ่และต้องทำงานซ้ำกับทดสอบใหม่จำนวนมากเสมอ ผมหยุดอยู่แถว ๆ Java 17~18 แต่คนที่ทำงานกับผมแทบไม่ได้ใช้เวอร์ชันใหม่เลย ในปี 2022 โปรเจกต์หนึ่งต้องอัปเดต JVM 1.5 แต่ไลบรารี third-party สำคัญรองรับแค่เวอร์ชันก่อน Java 1.7 ทำให้ยุ่งยากมาก เราพยายามหา source code มาคอมไพล์เอง แต่ขอบเขตก็ขยายใหญ่ขึ้นเรื่อย ๆ ผมเหนื่อยกับการที่ความเห็นไม่ตรงกับผู้บริหาร และสุดท้ายก็ตัดสินใจลาออกจากลูกค้าระดับบนสุดของ Fortune 10 ได้ยินมาว่าจนถึงตอนนี้ระบบนั้นก็ยังอัปเดตไม่ได้
    • ผมอยากลองกลับไปใช้แอป swing ที่เคยเขียนไว้ และคิดว่าน่าจะชุบชีวิตมันกลับมาได้โดยแทบไม่ต้องแก้อะไรมาก
    • JVM และ ecosystem ของมันสามารถใช้ร่วมกับภาษาอื่นอย่าง Scala, Clojure ฯลฯ ได้ด้วย เลยมีรูปแบบการใช้งานที่หลากหลายและน่าสนใจ
  • น่าแปลกใจที่การอนุญาตให้ตรวจสอบความถูกต้องและแปลงพารามิเตอร์ก่อนเรียก super ใน constructor ใช้เวลานานขนาดนี้กว่าจะมีได้ ผมรู้สึกมานานแล้วว่าพฤติกรรมเดิมมันขัดกับสัญชาตญาณ
    • ผมใช้ Java มาตั้งแต่ก่อน JDK 1.0 และเรื่องนี้ก็กวนใจผมมาตั้งแต่แรก แต่ตอนนี้ชินแล้วและคุ้นกับวิธี workaround ไปเรียบร้อย
    • ถ้าใช้ฟังก์ชัน static เพื่อทำขั้นตอน validate ให้กับพารามิเตอร์ของ super อยู่แล้ว จริง ๆ มันก็ถูกเรียกก่อน super อยู่ดี ดังนั้นคอมไพเลอร์ก็ไม่ได้มีปัญหาอะไร
  • ผมไม่ใช่นักพัฒนา Java แต่ส่วนตัวไม่ค่อยชอบระบบ import module เท่าไร ไวยากรณ์อย่าง import * ทำให้เขียนโค้ดง่ายก็จริง แต่ทำให้อ่านยากกว่ามาก โดยเฉพาะสำหรับนักพัฒนาที่ไม่คุ้นกับภาษาหรือ codebase นั้น ๆ C# กับ Nim ก็เป็นสไตล์แบบนั้นเหมือนกัน ซึ่งผมแทบอ่านไม่ออกเลยถ้าไม่มี IDE เพราะแบบนี้ผมเลยชอบตัวอย่าง alias สั้น ๆ แบบ Python มากกว่า (import torch.nn.functional as F)
    • ใน codebase ขนาดใหญ่ ปัญหาหลักของ import คือ "มันมาจากไหน?" จำเป็นต้องมี explicit import โดยเฉพาะตอน build พังหรือสับสนเรื่องเวอร์ชัน dependency ใน codebase เล็ก ๆ จะทำแบบไหนก็ไม่ค่อยสำคัญอยู่แล้ว ยังไงเดี๋ยวนี้ editor ก็มักซ่อนบรรทัด import ให้ เลยแทบไม่ได้มองมันโดยตรงอยู่แล้ว แค่คลิกโค้ดหรือกดคีย์ลัดเพื่อกระโดดไปดูได้ทันที ก็เลยไม่ค่อยสนใจ import เท่าไร
    • ผมคิดว่าที่ประสบการณ์กับ C# ไม่ค่อยดี น่าจะเป็นเพราะไม่ได้ใช้ Visual Studio ตัวจริง VSCode ก็ดีอยู่หรอก แต่ผมไม่เคยเปิดไฟล์ csproj หรือ sln ด้วย VSCode เลย อ้างอิงไว้ก่อนว่า Visual Studio ซื้อไลเซนส์ถาวรได้ที่ นี่ ในราคา $500 และใช้งานได้โดยไม่ต้องสมัครสมาชิกเพิ่ม
    • ผมไม่ค่อยเข้าใจการบ่นเรื่ององค์ประกอบของภาษาที่เข้าใจยากถ้าไม่มี IDE เพราะยังไงเราก็ดูโค้ดใน IDE อยู่แล้ว เลยคิดว่าไม่มีปัญหา คนที่ไม่ใช้ IDE ก็เหมือนทำให้ตัวเองลำบาก ส่วนการดูโค้ดบน GitHub ปกติก็ไม่ได้ลงลึกเพื่อวิเคราะห์การอ้างอิงขนาดนั้น ดังนั้นความไม่สะดวกเล็กน้อยเพื่อแลกกับความกระชับก็นับว่ายอมรับได้
    • เท่าที่ผมรู้ สไตล์นี้ตั้งใจทำมาเพื่อให้เขียนโปรแกรมแบบ single source file ได้ง่ายขึ้น
  • ฟีเจอร์ใหม่ถูกสรุปไว้ดีมากในหน้าอย่างเป็นทางการของ OpenJDK 25 และ Java 25 เป็น LTS release
    • หวังว่าวันที่ต้องทำ migration จาก 17 ไป 25 ในอีก 10 ปีข้างหน้าจะมาถึงไว ๆ
  • เป็นความรู้สึกส่วนตัว แต่ผมรู้สึกว่า Java แม้จะเป็นภาษาเก่าแล้ว แต่ตลอด 10 ปีที่ผ่านมาได้พัฒนาอย่างต่อเนื่อง ขณะที่ C++ กลับยิ่งยากขึ้น
  • น่าเสียดายที่ structured concurrency ยังไม่ได้ปล่อยแบบสมบูรณ์เสียทีเดียว ผมรอฟีเจอร์นี้อยู่มาก แต่ก็ดีใจที่มี Scoped Values เพิ่มเข้ามา แค่นี้อย่างเดียวก็คิดว่าเพียงพอให้สร้างโครงสร้างโค้ดสไตล์ "rails-like" ใน Java ได้ โดยไม่ต้องถล่มใช้ god-class หรือ god-object
    • เมื่อเทียบกับ C++ ที่ตอนนี้สับสนเพราะมีฟีเจอร์ที่ถูกทำให้เป็นมาตรฐานทั้งที่ยังไม่มี implementation ผมคิดว่าสถานการณ์ของ Java ที่ค่อย ๆ เดินหน้าแบบ preview ดีกว่ามาก
    • ผมหวังว่า structured concurrency จะรู้สึกเป็นความก้าวหน้าที่จับต้องได้ ไม่ใช่แค่หวานเลี่ยนแบบ async/await จากที่ดูตัวอย่างอย่างเดียวผมยังไม่มั่นใจ แต่จะคอยดูต่อไป
  • ไม่นานมานี้ผมตัดสินใจย้ายจาก JDK8 แล้วข้ามไป JDK21 เลย เพราะ 25 ก็ใกล้ออกแล้ว เลยเลือก 21 แทนที่จะหยุดที่ 17 สำหรับผม ช่วงที่ยากที่สุดคือการย้ายจาก 8 ไป 11 (เพราะมี module system ใหม่เข้ามา) หลังจากนั้นถือว่าง่าย ผมทำ Proof-of-Concept บน jdk17 แล้วมันก็ทำงานบน jdk21 ได้แทบเหมือนเดิมเลย (มีแค่ guice ที่ต้องอัปเกรด major version) อนึ่ง ผมคิดว่าการใช้ภาษา JVM อื่นแทน Java ก็น่าจะช่วยได้ด้วย
    • ทีมของเราย้ายจาก 8 ไป 17 แล้วยากมาก เราใช้ของที่ไม่เป็นทางการเยอะ อย่างพวกแพ็กเกจ sun และการย้ายจาก javax ไป jakarta ก็เป็นภาระเหมือนกัน แต่พอผ่านช่วงนั้นไปแล้ว การไป 21 หรือ 25 ก็รู้สึกว่าง่าย และหวังว่าจากนี้การตามเวอร์ชันใหม่อย่างต่อเนื่องจะง่ายกว่าสมัยก่อน
    • Java 9 คือช่วงเวลาแบบ Python 3 ของ ecosystem นี้ แต่ตอนนี้รู้สึกว่าทุกอย่างคลี่คลายเรียบร้อยแล้ว
    • อ้างอิงไว้ ผมเพิ่งย้ายจาก 17 ไป 21 ไม่นานนี้ และไม่มีปัญหาอะไรเลย มีแค่ประเด็นเล็กน้อยตอนอัปเกรด Gradle ไปพร้อมกัน (ซึ่งจริง ๆ เป็นคนละเรื่องกัน)
  • ฟีเจอร์ใหม่ของ Java 25 ถูกสรุปไว้ดีในโพสต์ของ baeldung
  • ผมสงสัยว่าสถานะทางกฎหมายของการใช้ Java ในตอนนี้เป็นอย่างไร ทั้งสำหรับโอเพนซอร์สและเชิงพาณิชย์ Oracle ผูกเทคโนโลยีดี ๆ อย่าง Truffle ไว้กับ Java อยู่ ผมเลยอยากรู้ว่าการใช้มันในโปรเจกต์ใหม่สมเหตุสมผลแค่ไหน
    • OpenJDK โดยพื้นฐานแล้วคือเวอร์ชันโอเพนไลเซนส์ที่มาจาก Oracle โดยตรง ถ้าไม่ชอบ Oracle ก็ใช้เวอร์ชันจากที่อื่นอย่าง Eclipse Foundation, Microsoft, Amazon ฯลฯ ได้ อายุใช้งานของ Java ยาวนานมาก ซึ่งก็เป็นเหตุผลที่คนยังใช้เวอร์ชันเก่าอย่าง 8/11 กันอยู่ แค่เขียนครั้งเดียวมันก็อยู่ได้นานจริง ๆ ในแง่ฟีเจอร์อาจจะช้ากว่าคู่แข่ง แต่สำหรับงานพัฒนาที่สำคัญก็เพียงพอ ถ้าคุณพึ่งพา JVM ผมแนะนำ Kotlin (โดยเฉพาะเพราะ Java ยังไม่มี nullable type ทำให้ NullPointerException ยังเจอบ่อย) ถ้าไม่ชอบ Kotlin, C# ก็เป็นตัวเลือกที่ดี ถึงอย่างนั้น Java ก็ยังใช้งานได้ดีพอ
    • ณ ตอนนี้ ถ้าเป็น Oracle distribution ก็ถือว่าใช้ latest LTS ได้อย่างสบายใจ ส่วนเวอร์ชันที่ต่ำกว่านั้นเป็นไลเซนส์ OTN ใช้ได้แค่ส่วนตัวหรือเพื่อการพัฒนา และใช้ production ไม่ได้ ถ้าไม่ได้ต้องการตรา Oracle โดยเฉพาะ OpenJDK หรือ JDK จากค่ายอื่นก็ไม่มีเรื่องไลเซนส์ให้น่ากังวล
    • OpenJDK เป็นโอเพนซอร์สเต็มรูปแบบ จึงไม่ต้องกังวลอะไรเลย
    • ถ้าใช้ของอย่าง OpenJDK ก็หลุดพ้นจากประเด็น Oracle ได้อย่างสมบูรณ์
    • ถ้าคุณไม่ได้จะสร้างและแจกจ่าย Java implementation เอง ประเด็นทางกฎหมายก็แทบไม่ใช่สิ่งที่ต้องเอามาคิดเลย