Jakarta EE 12 วางวันปล่อยแล้ว ทีม Java ไทยควรเผื่ออะไร

Jakarta EE 12 Core Profile วางเป้าหมายวันที่ 1 ธันวาคม ตาม Ivar Grimstad ผู้ส่งเสริมการใช้งาน Jakarta EE แห่ง Eclipse Foundation แปลว่า ทีม Java องค์กรมีวันอ้างอิงสำหรับเตรียมงานแล้ว แต่ข้อความนี้ยังไม่ระบุปีครับ (Hashtag Jakarta EE)

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

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

Grimstad เขียนว่าคณะกรรมการกำกับทิศทางขอให้หารือกำหนดการ และการประชุมฝั่งแพลตฟอร์มทำให้แผนชัดขึ้น InfoQ นำข้อความนั้นมารายงานต่อ โดยไม่ได้เติมปีกำกับวันและเดือนเช่นกัน (InfoQ)

• Core Profile: 1 ธันวาคม แปลว่า ชุดที่ใช้ชื่อ Core มีเป้าหมายออกก่อนชุดอื่นตามข้อความที่รายงาน (Grimstad)
• Web Profile: 31 มีนาคม แปลว่า งานฝั่งชุด Web มีวันเป้าหมายแยกจาก Core แต่ยังไม่ระบุปีในรายการนี้ (Grimstad)
• Platform: 15 พฤษภาคม แปลว่า ชุด Platform มีอีกวันเป้าหมายของตัวเอง ไม่ได้ออกพร้อมกันทั้งหมดตามรายการนี้ (InfoQ)

อีกเรื่องที่ยังอยู่ระหว่างตัดสินใจคือการรวม Jakarta Authorization ไว้ใน Web Profile ส่วน Jakarta NoSQL เป็นสิ่งที่ Grimstad ระบุว่าอยากเห็นเป็นการส่วนตัว ยังไม่ใช่ประกาศว่าถูกรวมแล้ว (InfoQ)

แล้ววันที่เหล่านี้หมายถึงวันที่ระบบของบริษัทเราพร้อมเปลี่ยนด้วยหรือ? ต้องแยกกำหนดของมาตรฐานออกจากกำหนดของซอฟต์แวร์ที่ใช้จริงก่อน ร่างแผนระบุเรื่องการประสานงานกับผู้พัฒนาซอฟต์แวร์ที่ทำตามมาตรฐานไว้ชัดเจน (ร่างแผน)

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

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

ถ้าคุณเป็นเจ้าของกิจการที่จ้างคนพัฒนาระบบ ควรให้ผู้รับจ้างแยกคำว่า “มาตรฐานออกแล้ว” กับ “ผลิตภัณฑ์ที่เราใช้รองรับแล้ว” ในแผนส่งมอบ ร่างแผนเองบอกว่าไม่มีอำนาจควบคุมวันออกของซอฟต์แวร์ที่รองรับมาตรฐาน จึงใช้วันในข่าวแทนคำรับรองจากผู้รับจ้างไม่ได้ (ร่างแผน)

สำหรับทีม Java ข่าวนี้มีประโยชน์ตรงช่วยเปิดการคุยเรื่องแผนงานล่วงหน้า ร่างแผนวางการปล่อย Platform ไว้ในช่วงไตรมาสแรกหรือไตรมาสสองของ 2027 แปลว่า มีกรอบปีสำหรับเตรียมงบทดสอบ แม้เอกสารยังไม่ได้ยืนยันวันละเอียดตามข่าวล่าสุด (ร่างแผน)

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

ทำงานยังไง

ในข่าวนี้ให้เข้าใจ Jakarta EE ว่าเป็นชุดข้อกำหนดสำหรับซอฟต์แวร์ Java ฝั่งองค์กร คำว่า ข้อกำหนด คือเอกสารที่ระบุสิ่งที่ซอฟต์แวร์ต้องทำตาม ส่วน compatible implementation คือซอฟต์แวร์จริงที่รองรับข้อกำหนดนั้น ร่างแผนแยกงานสองส่วนนี้ และกำหนดว่าต้องมีซอฟต์แวร์ที่รองรับก่อนส่งมาตรฐานฉบับสุดท้าย (ร่างแผน)

Profile ในการอ่านแผนนี้คือการแบ่งชุดมาตรฐานเป็นชื่อ Core และ Web ส่วน Platform คือชุดแพลตฟอร์มที่เอกสารกล่าวถึงแยกต่างหาก สำหรับจำชื่อแบบง่าย ให้คิดถึง Core ว่าชุดแกนหลัก Web ว่าชุดสำหรับงานเว็บ และ Platform ว่าภาพรวมแพลตฟอร์ม แต่แหล่งที่ให้มาไม่มีบัญชีองค์ประกอบครบ จึงยังใช้คำอธิบายสั้นนี้เลือกผลิตภัณฑ์ไม่ได้ (ร่างแผน)

เอกสารยังไม่ได้ให้ประวัติชื่อเดิม Java EE ไว้ในข้อความที่มี จึงไม่ขยายเรื่องการเปลี่ยนชื่อจากความจำครับ จุดที่ใช้วางแผนได้จริงคือแต่ละชุดมีงานตรวจสอบและขั้นตอนปล่อยของตัวเอง ไม่ควรเรียกทั้งหมดรวมว่า “เสร็จแล้ว” เพียงเพราะมีวันแรกในปฏิทิน (ร่างแผน)

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

ส่วนทีมของคุณต้องตรวจ “ห้อง” ของตัวเองด้วยการทดลองระบบจริง Application server หรือซอฟต์แวร์ที่ใช้เปิดให้โปรแกรมฝั่งองค์กรทำงาน เป็นรายการที่ควรบันทึกชื่อผู้ผลิตและรุ่นไว้ก่อน ความหมายนี้ใช้ช่วยทำบัญชีระบบ ไม่ได้ยืนยันว่าเซิร์ฟเวอร์ค่ายใดรองรับชุดใหม่แล้ว

ร่างแผนระบุ Java SE 21 เป็นขั้นต่ำของสภาพแวดล้อมที่ใช้รันซอฟต์แวร์ที่รองรับมาตรฐาน แปลว่า แผนทดลองควรตรวจความพร้อมของ Java รุ่นนี้ด้วย เอกสารยังกำหนดระดับการคอมไพล์ หรือการแปลงโค้ดให้พร้อมทำงาน สำหรับ Platform, Web และ Core ตามระดับเดียวกัน (ร่างแผน)

จุดหักมุม: วันชัดขึ้น แต่หลักฐานยังไม่ได้ครบทุกหน้า

แต่กำหนดที่ Grimstad บอกว่าหารือจนชัดขึ้น ยังอยู่คู่กับหน้าเอกสารภาพรวมที่ระบุว่ากำหนดการเป็นเพียงเบื้องต้นและเปลี่ยนได้ครับ คำว่าแผนชัดขึ้นจึงยังไม่เท่ากับคำรับรองว่าจะออกตรงวันแน่นอน (Grimstad, ภาพรวมร่างแผน)

ที่ต้องระวังอีกชั้นคือข้อความที่ได้จากหน้าโครงการ Eclipse ทั้ง Core และ Platform ไม่แสดงวันปล่อยรุ่นเลย เราจึงตรวจไม่ได้จากหลักฐานชุดนี้ว่าหน้าเหล่านั้นยังแสดงกำหนดเก่าต่างจากข่าวล่าสุดเท่าไร (หน้า Core, หน้า Platform)

มีช่องวันที่ในข้อมูลกำกับไฟล์ แต่เอามาใช้แทนวันปล่อยรุ่นไม่ได้ครับ ความต่างที่ยืนยันได้ตอนนี้คือข่าวมีวันและเดือน ส่วนร่างแผนมีกรอบไตรมาส ไม่ใช่หลักฐานว่ามีใครประกาศวันชนกันอย่างแน่นอน (InfoQ, ร่างแผน)

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

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

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

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

เรื่องฟีเจอร์ใหม่ก็มีผลกับขอบเขตงาน Grimstad สนับสนุนให้รวม Jakarta Authorization ซึ่งเป็นข้อกำหนดเกี่ยวกับการอนุญาตสิทธิ์ใช้งาน เข้า Web Profile เพราะเห็นว่าควรอยู่ร่วมกับข้อกำหนดความปลอดภัยอื่น แต่การลงคะแนนยังดำเนินอยู่ อย่าเขียนในสัญญาว่าได้ข้อสรุปแล้ว (InfoQ)

อีกข้อเสนอคือ Jakarta NoSQL ซึ่ง Grimstad อธิบายว่าอยากให้ช่วยทำการเข้าถึงแหล่งเก็บข้อมูล NoSQL ให้เรียบง่ายและเป็นมาตรฐาน เขาเชื่อมประโยชน์นี้กับงาน AI โดยเฉพาะฐานข้อมูลเวกเตอร์สำหรับ RAG หรือการค้นข้อมูลมาช่วยประกอบคำตอบของ AI ทั้งหมดนี้ยังเป็นเหตุผลสนับสนุนของเขา ไม่ใช่คำรับรองว่ารวมใน Web Profile แล้ว (Grimstad)

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

ฝั่งที่ให้ความมั่นใจเรื่องทิศทางคือ Grimstad เขาบอกว่าการประชุมทำให้กำหนดชัดขึ้น พร้อมเสนอวันแยกตามชุดมาตรฐาน แต่ InfoQ อ้างข้อความเดียวกัน จึงนับเป็นการรายงานยืนยันว่ามีคำกล่าวนั้น ไม่ใช่พยานอีกชุดที่รับรองวันปล่อยอย่างอิสระ (Grimstad, InfoQ)

ฝั่งที่เตือนเรื่องความแน่นอนคือเอกสารโครงการ Eclipse หน้าแนะนำร่างแผนบอกว่ากำหนดการยังเปลี่ยนได้ ส่วนร่างแผนให้กรอบไตรมาสสำหรับการลงคะแนนและการปล่อย Platform นี่เป็นข้อจำกัดจากเจ้าของโครงการ ไม่ใช่ความเห็นคัดค้านส่วนบุคคลที่ผมสร้างขึ้น (ภาพรวมร่างแผน, ร่างแผน)

เรื่องปีต้องเขียนอย่างระมัดระวัง ตารางในร่างแผนวางการลงคะแนน Core Profile ไว้ไตรมาสสุดท้ายของ 2026 แปลว่าเป็นช่วงเตรียมรับรองตามร่าง ไม่ใช่การยืนยันปีของวันธันวาคมในข้อความข่าวโดยตรง (ร่างแผน)

ตารางเดียวกันวางการลงคะแนน Web Profile และ Platform ไว้ไตรมาสแรกหรือไตรมาสสองของปีถัดไป แปลว่าให้กรอบลำดับงานกว้างๆ แต่ไม่ควรนำมาประกอบแล้วเขียนว่าวันและเดือนในข่าวมีปีกำกับแน่นอน ส่วนข้อความจากหน้าโครงการดูเก่ากว่าจากข้อมูลกำกับไฟล์ ก็ยังไม่พอพิสูจน์ว่าวันปล่อยบนหน้าเว็บเก่าแล้ว (ร่างแผน, หน้า Core, หน้า Platform)

เรื่อง NoSQL ก็ต้องแยกสถานะครับ InfoQ รายงานว่า Eclipse JNoSQL ซึ่งเป็นซอฟต์แวร์ที่รองรับ Jakarta NoSQL ได้เลื่อนจากโครงการบ่มเพาะเข้าสู่กลุ่ม Eclipse Enterprise for Java หรือ EE4J แล้ว แต่ความก้าวหน้าของโครงการซอฟต์แวร์นี้ ไม่ได้ตอบแทนผลตัดสินใจเรื่องสมาชิกของ Web Profile (InfoQ)

InfoQ ยังระบุว่า JNoSQL อยู่ใน Eclipse GlassFish ในฐานะส่วนหนึ่งของการรองรับ Jakarta Data ข้อมูลนี้ช่วยอธิบายว่ามีงานนำไปใช้จริงอยู่แล้ว แต่ไม่ได้บอกว่าทุก application server ต้องมีความสามารถเดียวกัน เราไม่ควรขยายข้อความจากผลิตภัณฑ์หนึ่งเป็นคำรับรองทั้งตลาด (InfoQ)

ถ้าผู้รับจ้างบอกว่า “รองรับแน่นอน” เขาอ้างผลตรวจของรุ่นไหน? หลักฐานชุดนี้ไม่มีรายชื่อรุ่นพร้อมใช้ของทุกค่าย ไม่มีผลทดสอบกับระบบไทย และไม่มีผู้คัดค้าน NoSQL ที่มีชื่อชัดเจน จึงยังตอบแทนผู้ผลิตหรือแต่งเสียงฝ่ายค้านขึ้นมาไม่ได้ครับ

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

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

คนทั่วไปและเจ้าของงานธุรกิจ

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

ทีม IT และผู้ดูแลงบประมาณ

1. ทำบัญชี application server ที่ใช้อยู่ ใส่ชื่อผู้ผลิต รุ่น ผู้ดูแล และระบบธุรกิจที่พึ่งพา อย่าเริ่มจากชื่อมาตรฐานอย่างเดียว เพราะต้องถามผู้ผลิตที่เกี่ยวข้องกับของจริง
2. ตรวจความพร้อมของ Java ตามขั้นต่ำที่ร่างแผนระบุ แล้วบันทึกว่าเป็นข้อกำหนดในร่าง รอเทียบกับเอกสารฉบับสุดท้ายก่อนล็อกเงื่อนไขจัดซื้อ (ร่างแผน)
3. กันช่วงทดสอบใน 2027 เป็นข้อเสนอเชิงวางแผนตามกรอบของร่าง แปลว่าเตรียมคนไว้ล่วงหน้า ไม่ได้ประกาศว่าต้องย้ายระบบปีนั้นทุกแห่ง (ร่างแผน)
4. แยกวันออกมาตรฐาน วันผลิตภัณฑ์พร้อม และวันองค์กรอนุมัติใช้งานจริงไว้ในแผนเดียวกัน ใส่เจ้าของคำตอบแต่ละช่อง เพื่อไม่ให้กำหนดจากข่าวกลายเป็นคำสัญญาโดยไม่มีผู้รับผิดชอบ

นักพัฒนาและผู้รับจ้าง

1. ระบุว่าระบบต้องการความสามารถใด แล้วเทียบกับรายการข้อกำหนดฉบับจริงก่อนเลือก Core, Web หรือ Platform ข้อความในแหล่งข่าวชุดนี้ยังไม่ให้รายการครบสำหรับตัดสินใจแทนคุณ
2. แยกข้อเสนอ Authorization และ NoSQL ออกจากรายการที่ยืนยันแล้ว ติดตามผลลงคะแนนก่อนเขียนว่าฟีเจอร์นั้นเป็นส่วนบังคับของชุดมาตรฐาน (Grimstad)
3. เตรียมชุดตรวจงานเดิมและบันทึกผลที่ส่งให้ฝ่ายธุรกิจอ่านได้ หากมีข้อผิดพลาด ให้ระบุงานที่กระทบและเงื่อนไขที่เกิด แทนการรายงานเพียงว่าเปิดโปรแกรมติด

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

ผมมองว่า…

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

ผมมองว่า ความคืบหน้าของ JNoSQL กับความอยากเห็น NoSQL ใน Web Profile ควรเป็นเหตุให้ติดตาม ไม่ควรเป็นเหตุให้ขายงานล่วงหน้าว่าได้แน่นอน สำหรับระบบที่คนต้องใช้งานทุกวัน สิ่งที่น่าให้ความสำคัญคือหลักฐานว่ารุ่นที่เลือกทำงานเดิมได้ และมีคนรับผิดชอบผลการทดสอบครับ

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

ปฏิทินที่มีประโยชน์ควรบอกทั้งวันเป้าหมายและเงื่อนไขที่ทำให้ทีมพร้อมใช้งานจริง จับตาเป้าหมาย Core Profile วันที่ 1 ธันวาคม ตามคำกล่าวที่ยังไม่ระบุปี แล้วรอเอกสารที่ยืนยันกำหนดพร้อมปีอย่างชัดเจน (Grimstad)

อีกเรื่องคือผลลงคะแนน Authorization และสถานะข้อเสนอ NoSQL ใน Web Profile เพราะข้อความล่าสุดยังแยกระหว่างการลงคะแนนที่กำลังดำเนินกับความต้องการส่วนบุคคลไว้ต่างกัน อย่ารวมเป็นรายการฟีเจอร์ยืนยันก่อนมีข้อสรุป (InfoQ)

ทีมของคุณมีชื่อผู้รับผิดชอบยืนยันการรองรับของ application server ที่ใช้อยู่แล้วหรือยังครับ?

Recap

• เกิดอะไรขึ้น: Grimstad รายงานว่าการประชุมทำให้กำหนด Jakarta EE ชุดใหม่ชัดขึ้น แต่ยังต้องติดตามเอกสารและผลิตภัณฑ์จริง
• วันที่ต้องจำ: Core ตั้งเป้า 1 ธันวาคม แปลว่าเป็นจุดเริ่มเตรียมแผน ไม่ใช่คำสั่งย้ายระบบ และข้อความข่าวไม่ระบุปี
• กำหนดอื่น: Web ตั้งเป้า 31 มีนาคม โดยข้อความข่าวไม่ระบุปี
• กำหนด Platform: เป้าหมาย 15 พฤษภาคม ยังต้องอ่านคู่กับสถานะร่างแผน
• ใครให้ข้อจำกัด: Eclipse ระบุว่ากำหนดเบื้องต้นเปลี่ยนได้ ส่วน InfoQ อ้างคำกล่าวของ Grimstad ไม่ใช่การรับรองวันอีกชุด
• ยังไม่รู้: วันพร้อมใช้ของแต่ละผู้ผลิต ผลลงคะแนน และวันปล่อยที่หน้าโครงการ Eclipse แสดงจริง เพราะข้อความที่ได้ไม่มีวันนั้น
• กระทบคุณ: เตรียมรายการระบบ เจ้าของงาน และงบทดสอบ แยกวันออกมาตรฐานจากวันอนุมัติใช้จริงในองค์กร
• ต้องจับตา: Java 21 เป็นขั้นต่ำตามร่าง แปลว่าควรตรวจความพร้อม แต่ยังต้องเทียบเอกสารสุดท้าย
• แหล่งอ้างอิง: 1 — Grimstad · 2 — InfoQ · 3 — ร่างแผน · 4 — Core · 5 — Platform · 6 — ภาพรวมแผน