เมื่อ Java กลายเป็นแพลตฟอร์มที่ไม่น่าพิศมัย

by bow_der_kleine
23 February 2013 - 11:02

เดิมที Java มักถูกวิจารณ์ในแง่ของแนวทางในการพัฒนาซอฟต์แวร์ที่มีความซับซ้อน และซอฟต์แวร์ที่ได้ใช้ทรัพยากรระบบมาก แต่ก็ยังเป็นแพลตฟอร์มได้รับความนิยมเนื่องเพราะ จำนวน ความหลากหลาย และขีดความสามารถของไลบรารี จำนวนผู้ใช้งาน ความปลอดภัย ค่าใช้จ่าย (ฟรี) ฯลฯ แต่หลังจากที่ Oracle ได้ซื้อ Java ไปจาก Sun ข่าวไม่ดีต่าง ๆ ได้ออกมาจำนวนมาก ไม่ว่าจะเป็นเรื่องความปลอดภัย (เฟซบุ๊ก, ทวิตเตอร์, แอปเปิล, ไมโครซอฟท์) การฟ้องร้อง และเตือนหรือห้ามไม่ใช้งาน Java ที่สำคัญท่าทีของ Oracle ที่มีต่อเรื่องราวทั้งหมดไม่น่าประทับใจเท่าไร (มีเรื่องหนึ่งที่ผมอ่านแล้วค่อนข้างตกใจคือ "ไม่จ่ายเรา เราไม่แก้บั๊กให้") การจะไปหวังพึ่งพาระบบเปิดจาก OpenJDK ก็พบกับปัจจัยเสี่ยงที่โครงการจะโดน Oracle ฟ้องในภายหลัง กล่าวโดยสรุปคือ Java กำลังจะกลายเป็นแพลตฟอร์มที่ไม่น่าใช้มากขึ้นเรื่อย ๆ

คำถามที่จะเกิดขึ้นคือ "แล้วเราจะใช้อะไรแทน Java?"

ทั้งนี้ต้องเข้าใจว่าปัญหาที่เกิดขึ้นเป็นปัญหาเกี่ยวกับ JVM ดังนั้นภาษาที่ขี่อยู่บน JVM ทั้งหมดเช่น Scala, Groovy หรือ Clojure จึงไม่ใช่คำตอบ

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

ดังนั้นเงื่อนไขแรกในการเลือกเทคโนโลยีที่จะมาแทน Java คือควรเป็นเทคโนโลยีโอเพนซอร์สที่ไม่ติดปัญหาเรื่องกฎหมายทรัพย์สินทางปัญญา

คำตอบที่ถูกต้องที่สุด แต่มีประโยชน์น้อยที่สุดคือ "ขึ้นอยู่กับการใช้งาน"

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

C/C++

ตัวเลือกนี้อาจไม่ถูกใจหลาย ๆ คนเพราะสร้างความลำบากในการพัฒนามากขึ้นหลายเท่าตัวเมื่อเทียบกับ Java แต่ก็เป็นตัวเลือกที่เราปฏิเสธหรือมองข้ามไม่ได้ ปัจจุบันยังมีซอฟต์แวร์จำนวนมากที่ใช้ C/C++ ในการพัฒนา ไม่เฉพาะซอฟต์แวร์ระดับรากหญ้า แต่รวมไปถึงซอฟต์แวร์ในระดับการใช้งานด้วย แต่ซอฟต์แวร์ที่ไม่เหมาะสำหรับ C/C++ เอาเสียเลยคือ Web-based Application ด้วยเหตุที่ C/C++ เป็นเทคโนโลยีรุ่นปู่ก็จะมีข้อดีข้อเสียที่ต้องพิจารณาดังนี้

ข้อดี

  • มีไลบรารีและเครื่องมือสำหรับการพัฒนาให้เลือกใช้มากมาย
  • เป็นเทคโนโลยีที่เป็นที่ยอมรับและเป็นที่รู้จักในวงกว้าง
  • นักพัฒนาที่หาได้ไม่ยากนัก (แต่หาเก่ง ๆ ยากหน่อย)
  • performance สูง ใช้ทรัพยากรระบบน้อย
  • ทำงานเข้ากับส่วนต่าง ๆ ของระบบได้เป็นอย่างดี ตั้งแต่ล่างสุดยันบนสุด
  • เป็นพื้นฐานของเทคโนโลยีเกือบทั้งหมด

ข้อเสีย

  • ในการพัฒนาซอฟต์แวร์ทำได้ยาก และใช้ระยะเวลานาน
  • เมื่อมันยากการสร้างบุคลากรก็ยากด้วย
  • การบริหารจัดการหน่วยความจำเอง นอกจากจะเหนื่อยแล้ว โอกาสที่ซอฟต์แวร์เน่าก็มีสูง
  • การคอมไพล์และจัดการแพกเกจ นอกจากจะยาก และซับซ้อนแล้ว สำหรับแต่ละแพลตฟอร์มก็ไม่เหมือนกันอีก แต่ก็พอมีเครื่องมือช่วยในเรื่องนี้อยู่หลายตัว

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

Script Language

ภาษาที่อยู่ในกลุ่มนี้ได้แก่ PHP, Python, Ruby, JavaScript และอาจรวมไปถึง Lua ซึ่งภาษาเหล่านี้นอกจากเป็นภาษาที่ได้รับความนิยมค่อนข้างมากแล้ว ยังเป็นภาษาที่ได้รับการพิสูจน์แล้วว่ามีความพร้อมในหลาย ๆ ด้าน สามารถนำมาใช้งานในระดับ production ได้อย่างไม่มีปัญหา ด้วยความที่ภาษาเหล่านี้เป็นภาษา dynamic และค่อนข้างใหม่เมื่อเทียบกับ C/C++ (ส่วนมากเกิดในยุค 1990 ตอนกลาง) ดังนั้นจึงมีความได้เปรียบดังต่อไปนี้

ข้อดี

  • ใช้เวลาในการพัฒนาที่สั้น จากประสบการณ์อาจสั้นกว่า C/C++ ประมาณ 5-10 เท่า
  • สร้างบุคลากรได้ง่าย
  • มีระบบจัดการหน่วยความจำอัตโนมัติโอกาสซอฟต์แวร์เน่ามีน้อยกว่า C/C++ มาก
  • เนื่องจากโค้ดที่เขียนสั้นกว่า โอกาสเกิดบั๊กมักน้อยกว่า
  • มีไลบรารีและเครื่องมือสำหรับการพัฒนาให้เลือกใช้มากมายเช่นกัน บางภาษาอย่าง Python ติดตั้งเสร็จมีโมดูลพร้อมใช้ให้เลือกมากมาย จนแทบไม่ต้องติดตั้งอะไรเพิ่ม
  • ระบบนิเวศในการพัฒนาซอฟต์แวร์ที่กะทัดรัด ไม่จำเป็นต้องใช้เครื่องมืออะไรมากมาย interpreter ตัวเดียวเอาอยู่ และขนาดของ interpreter ส่วนมากจะอยู่ในหลักสิบเมกะไบต์ ซึ่งถือว่าเล็กมาก
  • หานักพัฒนาง่าย (เป็นบางภาษา โดยเฉพาะ PHP หาง่ายสุด ๆ)
  • โดยทั่วไปจะใช้หน่วยความจำน้อย

ข้อเสีย

  • performance ต่ำ แม้จะมีเทคนิคที่จะเขียนให้เร็วได้ แต่ก็ต้องใช้ประสบการณ์สูง
  • การขยายระบบทำได้ยากกว่า แต่ปัจจุบันมี Cloud เข้ามาช่วย ปัญหาเหล่านี้จึงค่อย ๆ ลดลง
  • ระบบ type ที่เป็น dynamic แม้จะมีข้อดีมากมาย แต่ไม่มีเครื่องมือตรวจสอบความถูกต้องพื้นฐานอย่าง compiler ทำให้ข้อผิดพลาดหลาย ๆ อย่างจะถูกตรวจพบตอน run time
  • การ refactoring มีโอกาสสร้างความผิดพลาดในระบบได้สูง
  • ต้องมีการทดสอบที่เข้มข้นกว่าภาษาที่ต้องมีการ compile
  • การทำในรูปแบบธุรกิจจะทำได้ยากกว่า เพราะโดยปกติซอฟต์แวร์จะรันจากโค้ดโดยตรง ในกรณีที่ต้องการซ่อนโค้ด ต้องใช้เครื่องมืออื่น ๆ เพิ่มเติม เช่น py2exe

จะเห็นได้ว่าการนำ C/C++ มาช่วย โดยการเขียนระบบพื้นฐาน จะช่วยได้แค่ข้อจำกัดในส่วนของ performance เท่านั้น และข้อจำกัดต่าง ๆ เกิดจากธรรมชาติของภาษา dynamic เอง เทคโนโลยีในกลุ่มสุดท้ายจะอยู่ตรงกลางระหว่างสองกลุ่มแรก คล้าย ๆ กับที่ Java เป็น

ภาษาเกิดใหม่

ในระยะหลังแนวทางของภาษาเกิดใหม่ค่อนข้างมีแนวโน้มไปในทิศทางเดียวกันคือ เป็นภาษาแบบ compile ที่มีความยืดหยุ่นในระบบ type มากขึ้น และมีกลิ่นอายของภาษา functional มากขึ้น ภาษาในกลุ่มนี้ได้แก่ Go, Vala, D, Rust เป็นต้น โดยภาษาที่ผมจะโฟกัสมากเป็นพิเศษคือ Vala และ D เนื่องจากทั้งสองภาษามีความพร้อมในการใช้งานมากกว่าภาษาอื่น ๆ ในงานที่ผมทำอยู่ตอนนี้ ผมเลือกที่จะใช้ Vala เพราะมีความพร้อมด้านไลบรารีมากกว่า (Vala ใช้งานไลบรารีของโครงการ GNU และ GNOME ได้เกือบทั้งหมด) แต่ D จะมีข้อได้เปรียบในส่วนของ features ของภาษา

ข้อดี

  • ในกรณีส่วนใหญ่ performance ของ Vala และ D ไม่ต่างกับ C/C++ มากนัก
  • Vala และ D มีโครงสร้างคล้าย ๆ Java หรือ C# การศึกษาทำความเข้าใจทำได้ไม่ยาก (แต่ก็ขาดความเซ็กซี่ไปในตัว)
  • ใช้งานง่าย ทั้ง Vala และ D มี feature และไลบรารีที่ช่วยให้พัฒนาง่ายกว่า Java ด้วยซ้ำ แต่ก็ไม่ง่ายไปกว่าภาษาสคริปต์
  • มีระบบ type ที่เข้มงวดขึ้น ลดความผิดพลาดบางอย่างลง
  • มีระบบบริหารจัดการหน่วยความจำที่มีประสิทธิภาพ โดยใช้ reference counting แต่ไม่ครอบคลุมทุกกรณี อาจทำให้ซอฟต์แวร์เน่าได้ แต่มีความเสี่ยงน้อยกว่า C/C++ มาก
  • ทำงานร่วมกับ C ได้ดี ทำให้มีโอกาสเข้าถึงไลบรารีจำนวนมากได้

ข้อเสีย

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

ไม่มีใครได้ทุกอย่าง ดังนั้นจึงต้องมีการเลือกเกิดขึ้น ข่าวร้ายคือ ทุกตัวเลือกมีความเสี่ยง โดยส่วนตัวผมเลือก Vala เพราะพัฒนาได้ไม่ยากนัก แต่ performance สูง โดยผมต้องเสี่ยงกับปัจจัยที่เกิดจากความใหม่ของภาษา ซึ่งผมวิเคราะห์ว่าปัญหาเหล่านั้นจะมีแนวโน้มไปในทางที่ดีขึ้น เนื่องจากตอนนี้โครงการจำนวนมากของ GNOME ได้หันไปใช้ Vala เป็นภาษาหลัก โดยเฉพาะอย่างยิ่งโครงการในความดูแลของ Canonical ดังนั้นซอฟต์แวร์ใหม่ ๆ บน Ubuntu จะค่อย ๆ ทยอยหันไปใช้ Vala

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

Blognone Jobs Premium