แอปเพล็ต Java
Java appletsคือแอปพลิเคชันขนาดเล็กที่เขียนด้วย ภาษาโปรแกรม Javaหรือภาษาโปรแกรม อื่น ๆ ที่คอมไพล์เป็นJava bytecodeและส่งไปยังผู้ใช้ในรูปแบบของJava bytecode
ในขณะที่เปิดตัว จุดประสงค์ของการใช้งานคือเพื่อให้ผู้ใช้เปิดแอปเพล็ตจากหน้าเว็บและเพื่อให้แอปเพล็ตทำงานภายในเครื่องเสมือน Java (JVM) ในกระบวนการที่แยกต่างหากจากเว็บเบราว์เซอร์แอปเพล็ต Java สามารถปรากฏในเฟรมของหน้าเว็บ หน้าต่างแอปพลิเคชันใหม่ โปรแกรมจากSunที่เรียกว่า appletviewer [ 6 ]หรือเครื่องมือแบบสแตนด์อะโลนสำหรับการทดสอบแอปเพล็ต
Java applets ถูกนำมาใช้ในภาษา Java เวอร์ชันแรก ซึ่งเปิดตัวในปี 1995 ตั้งแต่ปี 2013 เว็บเบราว์เซอร์หลักๆ เริ่มทยอยยกเลิกการสนับสนุนNPAPIซึ่งเป็นเทคโนโลยีพื้นฐานที่ applets ใช้ในการทำงาน และ applets ก็ไม่สามารถทำงานได้อย่างสมบูรณ์ในช่วงปี 2015-2017 Java applets ถูกยกเลิก การใช้งาน ใน Java 9 ในปี 2017 [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] ถูกยกเลิกการ ใช้งานเพื่อเตรียมลบออกใน Java 17 ในปี 2021 [ 12 ]และถูกลบออกใน Java 26 ในปี2026 [ 13 ] [ 14 ]
โดยทั่วไปแล้วแอปเพล็ต Java จะเขียนด้วยภาษา Java แต่ภาษาอื่นๆ เช่นJython , JRuby , Pascal , [ 15 ] Scala , NetRexxหรือEiffel (ผ่านSmartEiffel ) ก็สามารถใช้ได้เช่นกัน
แตกต่างจาก JavaScript เวอร์ชันแรกๆ แอปเพล็ต Java สามารถเข้าถึงการเร่งความเร็วฮาร์ดแวร์ 3 มิติ ทำให้เหมาะสำหรับการแสดงภาพที่ไม่ธรรมดาและต้องใช้การคำนวณอย่างหนัก นับตั้งแต่มีการแนะนำแอปเพล็ต JavaScript ได้รับการสนับสนุนสำหรับกราฟิกที่เร่งความเร็วด้วยฮาร์ดแวร์ผ่าน เทคโนโลยี canvas (หรือโดยเฉพาะWebGLจากนั้นWebGPUในกรณีของกราฟิก 3 มิติ) [ 16 ] [ 17 ]รวมถึง การคอมไพล์ แบบjust-in-time [ 18 ]
เนื่องจากไบต์โค้ดของ Java เป็นแบบข้ามแพลตฟอร์ม (หรือไม่ขึ้นอยู่กับแพลตฟอร์ม) แอปเพล็ต Java จึงสามารถทำงานบนไคลเอ็นต์สำหรับหลายแพลตฟอร์ม รวมถึงMicrosoft Windows , FreeBSD , Unix , macOSและLinuxได้ อย่างไรก็ตาม แอปเพล็ตเหล่านี้ไม่สามารถทำงานบนอุปกรณ์เคลื่อนที่ได้ เนื่องจากอุปกรณ์เคลื่อนที่ไม่รองรับการทำงานของไบต์โค้ด Oracle JVM มาตรฐาน ส่วน อุปกรณ์ Androidสามารถรันโค้ดที่เขียนด้วย Java ที่คอมไพล์สำหรับAndroid Runtimeได้
ภาพรวม
แอปเพล็ตถูกใช้เพื่อเพิ่มคุณสมบัติแบบโต้ตอบให้กับแอปพลิเคชันบนเว็บ ซึ่งไม่สามารถทำได้ด้วยHTMLเพียงอย่างเดียว แอปเพล็ตสามารถรับอินพุตจากเมาส์และมีส่วนควบคุม เช่นปุ่มหรือช่องทำเครื่องหมายและสามารถเปลี่ยนเนื้อหากราฟิกที่แสดงตามการกระทำของผู้ใช้ได้ ทำให้แอปเพล็ตเหมาะอย่างยิ่งสำหรับการสาธิต การแสดงภาพ และการสอน มีชุดแอปเพล็ตออนไลน์สำหรับการศึกษาในหลากหลายวิชา ตั้งแต่ฟิสิกส์ไปจนถึงสรีรวิทยาของหัวใจ
แอปเพล็ตอาจเป็นเพียงพื้นที่ข้อความเท่านั้น ตัวอย่างเช่น อาจทำหน้าที่เป็นส่วนติดต่อบรรทัดคำสั่ง แบบข้ามแพลตฟอร์ม สำหรับระบบระยะไกลบางระบบ หากจำเป็น แอปเพล็ตสามารถออกจากพื้นที่ที่กำหนดและทำงานเป็นหน้าต่างแยกต่างหากได้ อย่างไรก็ตาม แอปเพล็ตมีการควบคุมเนื้อหาของเว็บเพจภายนอกพื้นที่ที่กำหนดของแอปเพล็ตน้อยมาก ดังนั้นจึงมีประโยชน์น้อยกว่าในการปรับปรุงรูปลักษณ์ของเว็บไซต์โดยทั่วไป เมื่อเทียบกับส่วนขยายเบราว์เซอร์ ประเภทอื่น (แม้ว่าจะมีแอปเพล็ตเช่นแถบข่าวหรือ โปรแกรมแก้ไข WYSIWYGที่รู้จักกันดี) แอปเพล็ตยังสามารถเล่นสื่อในรูปแบบที่ไม่ได้รับการสนับสนุนโดยธรรมชาติของเบราว์เซอร์ได้อีกด้วย
หน้าเว็บที่เขียนด้วย HTML อาจฝังพารามิเตอร์ไว้ภายใน ซึ่งจะถูกส่งไปยังแอปเพล็ต ด้วยเหตุนี้ แอปเพล็ตเดียวกันจึงอาจมีลักษณะที่แตกต่างกันไป ขึ้นอยู่กับพารามิเตอร์ที่ส่งผ่าน
เนื่องจากแอปเพล็ตมีให้ใช้งานก่อนHTML5 และ อินเทอร์เฟซDOM ของ CSSและJavaScriptที่ทันสมัยเป็นมาตรฐาน จึงมีการใช้งานอย่างแพร่หลายสำหรับเอฟเฟกต์ง่ายๆ เช่นการวางเมาส์เหนือองค์ประกอบและปุ่มนำทาง อย่างไรก็ตาม วิธีการนี้ก่อให้เกิดปัญหาใหญ่ด้านการเข้าถึงและการใช้ทรัพยากรระบบอย่างไม่เหมาะสม ปัจจุบันจึงไม่นิยมใช้แล้ว และถูกห้ามอย่างเด็ดขาดแม้ในขณะนั้นก็ตาม
ข้อมูลทางเทคนิค
เบราว์เซอร์ส่วนใหญ่เรียกใช้แอปเพล็ต Java ในแซนด์บ็อกซ์ซึ่งป้องกันไม่ให้แอปเพล็ตเข้าถึงข้อมูลภายในเครื่อง เช่นระบบไฟล์[ 19 ]โค้ดของแอปเพล็ตจะถูกดาวน์โหลดจากเว็บเซิร์ฟเวอร์หลังจากนั้นเบราว์เซอร์จะฝัง แอปเพล็ตลงในหน้าเว็บหรือเปิดหน้าต่างใหม่เพื่อแสดง อินเทอร์เฟซผู้ใช้ของแอปเพล็ต
การใช้งานในระยะแรกนั้นเกี่ยวข้องกับการดาวน์โหลดคลาสของแอปเพล็ตทีละคลาส แม้ว่าคลาสจะเป็นไฟล์ขนาดเล็ก แต่ก็มักจะมีจำนวนมาก ทำให้แอปเพล็ตได้รับชื่อเสียงว่าเป็นส่วนประกอบที่โหลดช้า อย่างไรก็ตาม นับตั้งแต่.jarมีการนำไฟล์มาใช้ แอปเพล็ตมักจะถูกส่งมาเป็นไฟล์เดียวที่มีขนาดใกล้เคียงกับไฟล์รูปภาพ (หลายร้อยกิโลไบต์ถึงหลายเมกะไบต์)
ไลบรารีระบบและรันไทม์ของ Java สามารถใช้งานร่วมกับเวอร์ชันเก่าได้ ทำให้สามารถเขียนโค้ดที่ทำงานได้ทั้งบน Java Virtual Machine เวอร์ชันปัจจุบันและเวอร์ชันในอนาคต
เทคโนโลยีที่คล้ายคลึงกัน
นักพัฒนา Java หลายคน บล็อก และนิตยสารต่างแนะนำให้ ใช้เทคโนโลยี Java Web Startแทนแอปเพล็ต[ 20 ] Java Web Start อนุญาตให้เรียกใช้โค้ดแอปเพล็ตที่ไม่ได้รับการแก้ไข ซึ่งจะทำงานในหน้าต่างแยกต่างหาก (ไม่ใช่ภายในเบราว์เซอร์ที่เรียกใช้)
บางครั้ง Java Servletถูกเปรียบเทียบอย่างไม่เป็นทางการว่า "คล้าย" กับแอปเพล็ตฝั่งเซิร์ฟเวอร์ แต่แท้จริงแล้วมันแตกต่างกันในด้านภาษา ฟังก์ชัน และคุณลักษณะแต่ละอย่างที่อธิบายไว้เกี่ยวกับแอปเพล็ตในที่นี้
การฝังลงในหน้าเว็บ
แอปเพล็ตจะแสดงบนหน้าเว็บโดยใช้appletแท็ก HTML ที่เลิกใช้แล้ว [ 21 ]หรือobjectแท็ก ที่แนะนำ [ 22 ] แท็ก นี้embedสามารถใช้ได้[ 23 ]กับเบราว์เซอร์ตระกูล Mozilla ( embedถูกเลิกใช้แล้วใน HTML 4 แต่รวมอยู่ใน HTML 5) ซึ่งระบุแหล่งที่มาและตำแหน่งของแอปเพล็ต ทั้ง แท็ก objectและembedสามารถดาวน์โหลดและติดตั้ง Java virtual machine (หากจำเป็น) หรืออย่างน้อยก็พาไปยังหน้าปลั๊กอินได้ แท็ก appletและobjectยังรองรับการโหลดแอปเพล็ตแบบอนุกรมที่เริ่มต้นในสถานะเฉพาะ (แทนที่จะเป็นสถานะเริ่มต้น) แท็ก ยังระบุข้อความที่จะแสดงแทนแอปเพล็ตหากเบราว์เซอร์ไม่สามารถเรียกใช้งานได้ด้วยเหตุผลใดๆ ก็ตาม
อย่างไรก็ตาม แม้ว่าobjectแท็กดังกล่าวจะได้รับการแนะนำอย่างเป็นทางการในปี 2010 แต่การสนับสนุนobjectแท็กดังกล่าวก็ยังไม่สม่ำเสมอในหมู่เบราว์เซอร์ และ Sun ยังคงแนะนำappletแท็กเก่าสำหรับการใช้งานในสภาพแวดล้อมที่มีหลายเบราว์เซอร์[ 24 ]เนื่องจากยังคงเป็นแท็กเดียวที่ได้รับการสนับสนุนอย่างสม่ำเสมอจากเบราว์เซอร์ยอดนิยมส่วนใหญ่ เพื่อรองรับเบราว์เซอร์หลายตัว การใช้objectแท็กเพื่อฝังแอปเพล็ตจะต้องใช้ JavaScript (ที่รู้จักเบราว์เซอร์และปรับแท็ก) การใช้แท็กเฉพาะเบราว์เซอร์เพิ่มเติม หรือการส่งเอาต์พุตที่ปรับเปลี่ยนจากฝั่งเซิร์ฟเวอร์
ปลั๊กอินเบราว์เซอร์ Java อาศัยNPAPIซึ่งผู้ผลิตเบราว์เซอร์เกือบทั้งหมดได้ยกเลิกการสนับสนุนหรือไม่นำไปใช้เนื่องจากความเก่าและปัญหาด้านความปลอดภัย ในเดือนมกราคม 2016 Oracle ได้ประกาศว่าสภาพแวดล้อมรันไทม์ Java ที่ใช้ JDK 9 จะยุติการใช้งานปลั๊กอินเบราว์เซอร์[ 25 ]
ข้อดี
แอปเพล็ต Java อาจมีข้อดีอย่างใดอย่างหนึ่งหรือทั้งหมดดังต่อไปนี้: [ 26 ]
- การทำให้มันใช้งานได้บน FreeBSD, Linux, Microsoft Windows และ macOS นั้นง่ายมาก กล่าวคือมันสามารถใช้งานได้ข้ามแพลตฟอร์ม แอปเพล็ตได้รับการสนับสนุนจากเว็บเบราว์เซอร์ ส่วนใหญ่ ในช่วงทศวรรษแรกของศตวรรษที่ 21 อย่างไรก็ตาม ตั้งแต่นั้นมา เบราว์เซอร์ส่วนใหญ่ได้ยกเลิกการสนับสนุนแอปเพล็ตด้วยเหตุผลด้านความปลอดภัย
- แอปเพล็ตเดียวกันนี้จะทำงานได้กับ Java ทุกเวอร์ชันที่ติดตั้งไว้ในเวลาเดียวกัน ไม่ใช่แค่ เวอร์ชัน ปลั๊กอิน ล่าสุด เท่านั้น อย่างไรก็ตาม หากแอปเพล็ตต้องการJava Runtime Environment (JRE) เวอร์ชันที่ใหม่กว่า ลูกค้าจะต้องรอในระหว่างการดาวน์โหลดขนาดใหญ่
- เว็บเบราว์เซอร์ส่วนใหญ่จะแคชแอปเพล็ตไว้ ทำให้โหลดได้เร็วเมื่อกลับมายังหน้าเว็บนั้น แอปเพล็ตยังทำงานได้ดีขึ้นเมื่อใช้งานไปเรื่อยๆ: หลังจากเรียกใช้แอปเพล็ตแรกแล้ว JVM ก็จะเริ่มทำงาน และแอปเพล็ตถัดไปก็จะเริ่มต้นได้อย่างรวดเร็ว (JVM จะต้องรีสตาร์ททุกครั้งที่เบราว์เซอร์เริ่มต้นใหม่) อย่างไรก็ตาม JRE เวอร์ชัน 1.5 ขึ้นไปจะรีสตาร์ท JVM เมื่อเบราว์เซอร์เปลี่ยนหน้าเว็บ เพื่อเป็นมาตรการรักษาความปลอดภัย ซึ่งทำให้ประสิทธิภาพที่ดีขึ้นนั้นหายไป
- เป็นการย้ายการทำงานจากเซิร์ฟเวอร์ไปยังไคลเอ็นต์ทำให้โซลูชันเว็บสามารถปรับขนาดได้มากขึ้นตามจำนวนผู้ใช้/ไคลเอ็นต์
- หากโปรแกรมแบบสแตนด์อโลน (เช่นGoogle Earth ) ติดต่อกับเว็บเซิร์ฟเวอร์ โดยปกติแล้วเซิร์ฟเวอร์นั้นจะต้องรองรับเวอร์ชันก่อนหน้าทั้งหมดสำหรับผู้ใช้ที่ไม่ได้อัปเดตซอฟต์แวร์ไคลเอ็นต์ของตน ในทางตรงกันข้าม เบราว์เซอร์จะโหลด (และแคช) แอปเพล็ตเวอร์ชันล่าสุด ดังนั้นจึงไม่จำเป็นต้องรองรับเวอร์ชันเก่า
- แอปเพล็ตนี้รองรับการเปลี่ยนแปลงสถานะของผู้ใช้ได้อย่างเป็นธรรมชาติ เช่น ตำแหน่งของตัวหมากบนกระดานหมากรุก
- นักพัฒนาสามารถพัฒนาและดีบักแอปเพล็ตได้โดยตรงเพียงแค่สร้างรูทีนหลัก (ไม่ว่าจะในคลาสของแอปเพล็ตหรือในคลาสแยกต่างหาก) และเรียกใช้ init() และ start() บนแอปเพล็ต ซึ่งช่วยให้สามารถพัฒนาใน สภาพแวดล้อมการพัฒนา Java SE ที่พวกเขาชื่นชอบได้ สิ่งที่ต้องทำก็คือทดสอบแอปเพล็ตอีกครั้งในโปรแกรม AppletViewer หรือเว็บเบราว์เซอร์เพื่อให้แน่ใจว่าเป็นไปตามข้อจำกัดด้านความปลอดภัย
- แอ ปเพล็ต ที่ไม่น่าเชื่อถือจะไม่สามารถเข้าถึงเครื่องโลคัลได้ และสามารถเข้าถึงได้เฉพาะเซิร์ฟเวอร์ที่มันมาจากเท่านั้น ทำให้แอปเพล็ตมีความปลอดภัยในการใช้งานมากกว่าไฟล์ปฏิบัติการดั้งเดิมที่มันมาแทนที่ อย่างไรก็ตาม แอปเพล็ตที่ลงนามแล้วจะสามารถเข้าถึงเครื่องที่มันกำลังทำงานอยู่ได้อย่างเต็มที่ หากผู้ใช้ยินยอม
- Java applets ทำงานได้เร็ว โดยมีประสิทธิภาพใกล้เคียงกับซอฟต์แวร์ที่ติดตั้งในเครื่อง
ข้อเสีย
เมื่อเปรียบเทียบกับเทคโนโลยีเว็บฝั่งไคลเอ็นต์อื่นๆ แล้ว Java applets มีข้อเสียดังต่อไปนี้:
- แอปเพล็ต Java จำเป็นต้องอาศัย Java Runtime Environment (JRE) ซึ่งเป็นซอฟต์แวร์ที่ซับซ้อนและมีขนาดใหญ่ นอกจากนี้ยังมักต้องการปลั๊กอินสำหรับเว็บเบราว์เซอร์ด้วย บางองค์กรอนุญาตให้ติดตั้งซอฟต์แวร์โดยผู้ดูแลระบบเท่านั้น ส่งผลให้ผู้ใช้ไม่สามารถดูแอปเพล็ตได้ เว้นแต่ว่าแอปเพล็ตนั้นมีความสำคัญมากพอที่จะต้องติดต่อผู้ดูแลระบบเพื่อขอติดตั้ง JRE และปลั๊กอิน
- หากแอปเพล็ตต้องการ JRE เวอร์ชันใหม่กว่าที่มีอยู่ในระบบ ผู้ใช้ที่เรียกใช้แอปเพล็ตเป็นครั้งแรกจะต้องรอให้การดาวน์โหลด JRE ขนาดใหญ่เสร็จสมบูรณ์
- เบราว์เซอร์มือถือบนiOSหรือAndroidไม่เคยรัน Java applet เลย[ 27 ]แม้กระทั่งก่อนการยกเลิกการใช้งาน applet บนทุกแพลตฟอร์ม เบราว์เซอร์เดสก์ท็อปก็ได้ยกเลิกการสนับสนุน Java applet ไปพร้อมๆ กับการเพิ่มขึ้นของระบบปฏิบัติการมือถือ
- ไม่มีมาตรฐานใดที่จะทำให้เนื้อหาของแอปเพล็ตสามารถใช้งานได้กับโปรแกรมอ่านหน้าจอ ดังนั้น แอปเพล็ตจึงส่งผลเสียต่อการเข้าถึงเว็บไซต์สำหรับผู้ใช้ที่มีความต้องการพิเศษ
- เช่นเดียวกับการเขียนสคริปต์ฝั่งไคลเอ็นต์ทั่วไป ข้อจำกัดด้านความปลอดภัยทำให้แอปเพล็ตที่ไม่น่าเชื่อถือบางตัวบรรลุเป้าหมายที่ต้องการได้ยากหรือแทบเป็นไปไม่ได้เลย วิธีเดียวที่จะให้สิทธิ์การเข้าถึงระบบไฟล์ในเครื่องหรือคลิปบอร์ดของระบบ หรือแหล่งข้อมูลเครือข่ายอื่นนอกเหนือจากแหล่งที่ให้บริการแอปเพล็ตแก่เบราว์เซอร์ คือการแก้ไขไฟล์ java.policy ในการติดตั้ง JAVA JRE เท่านั้น
- ผู้ใช้ส่วนใหญ่ไม่สนใจความแตกต่างระหว่างแอปเพล็ตที่ไม่น่าเชื่อถือและแอปเพล็ตที่น่าเชื่อถือ ดังนั้นการแบ่งแยกนี้จึงไม่ได้ช่วยเรื่องความปลอดภัยมากนัก ในที่สุดความสามารถในการเรียกใช้แอปเพล็ตที่ไม่น่าเชื่อถือก็ถูกลบออกไปทั้งหมดเพื่อแก้ไขปัญหานี้ ก่อนที่จะลบแอปเพล็ตทั้งหมดออกไปในที่สุด
คดีความที่เกี่ยวข้องกับความเข้ากันได้
Sunพยายามอย่างมากเพื่อให้มั่นใจได้ว่า Java เวอร์ชันต่างๆ จะใช้งานร่วมกันได้แม้ว่าจะมีการพัฒนาอย่างต่อเนื่อง โดยบังคับใช้กฎหมายเกี่ยวกับการพกพา Java หากจำเป็น ดูเหมือนว่า Oracle ก็กำลังดำเนินกลยุทธ์เดียวกันนี้ต่อไป
ปี 1997: ซัน ปะทะ ไมโครซอฟต์
คดีความในปี 1997 [ 28 ]ถูกยื่นฟ้องหลังจากที่ Microsoft สร้างJava Virtual Machine ที่ได้รับการดัดแปลงขึ้นเองซึ่งมาพร้อมกับ Internet Explorer Microsoft ได้เพิ่มเมธอดประมาณ 50 เมธอดและฟิลด์ประมาณ 50 ฟิลด์[ 28 ]เข้าไปในคลาสภายใน แพ็กเกจ java.awt, java.langและjava.ioการแก้ไขอื่นๆ รวมถึงการลบ ความสามารถ RMIและการแทนที่Java Native Interfaceจาก JNI เป็นRNIซึ่งเป็นมาตรฐานที่แตกต่างกัน RMI ถูกลบออกเนื่องจากรองรับการสื่อสารระหว่าง Java กับ Java ได้ง่ายเท่านั้นและแข่งขันกับ เทคโนโลยี DCOM ของ Microsoft แอปเพล็ตที่อาศัยการเปลี่ยนแปลงเหล่านี้หรือใช้งานโดยไม่ได้ตั้งใจจะทำงานได้เฉพาะภายในระบบ Java ของ Microsoft เท่านั้น Sun ฟ้องร้องในข้อหาละเมิดเครื่องหมายการค้าเนื่องจากจุดประสงค์ของ Java คือไม่ควรมีส่วนขยายที่เป็นกรรมสิทธิ์และโค้ดควรใช้งานได้ทุกที่ Microsoft ตกลงที่จะจ่ายเงินให้ Sun 20 ล้านดอลลาร์ และ Sun ตกลงที่จะให้สิทธิ์ใช้งานแบบจำกัดแก่ Microsoft ในการใช้ Java โดยไม่มีการแก้ไขเท่านั้นและในระยะเวลาจำกัด[ 29 ]
ปี 2002: ซัน ปะทะ ไมโครซอฟต์
ไมโครซอฟต์ยังคงจัดส่ง Java virtual machine ที่ไม่ได้ดัดแปลงของตนเองต่อไป เมื่อเวลาผ่านไปมันกลายเป็นสิ่งที่ล้าสมัยอย่างมาก แต่ก็ยังคงเป็นค่าเริ่มต้นสำหรับ Internet Explorer การศึกษาในภายหลังเปิดเผยว่าแอปเพล็ตในช่วงเวลานั้นมักจะมีคลาสของตัวเองที่จำลองSwingและคุณสมบัติใหม่ๆ อื่นๆ ในลักษณะที่จำกัด[ 30 ]ในปี 2545 ซันได้ยื่น ฟ้องคดี ต่อต้านการผูกขาดโดยอ้างว่าความพยายามในการผูกขาดอย่างผิดกฎหมายของไมโครซอฟต์ได้สร้างความเสียหายให้กับแพลตฟอร์ม Java ซันเรียกร้องให้ไมโครซอฟต์แจกจ่ายการใช้งานไบนารีปัจจุบันของเทคโนโลยี Java ของซันเป็นส่วนหนึ่งของ Windows แจกจ่ายเป็นการอัปเดตที่แนะนำสำหรับระบบปฏิบัติการเดสก์ท็อปของไมโครซอฟต์รุ่นเก่า และหยุดการแจกจ่าย Virtual Machine ของไมโครซอฟต์ (เนื่องจากระยะเวลาการอนุญาตใช้งานที่ตกลงกันไว้ในคดีก่อนหน้านี้ได้หมดอายุลงแล้ว) [ 29 ]ไมโครซอฟต์จ่ายเงิน 700 ล้านดอลลาร์สำหรับปัญหาต่อต้านการผูกขาดที่ค้างอยู่ อีก 900 ล้านดอลลาร์สำหรับปัญหาด้านสิทธิบัตร และค่าลิขสิทธิ์ 350 ล้านดอลลาร์เพื่อใช้ซอฟต์แวร์ของซันในอนาคต[ 31 ]
ความปลอดภัย
มีแอปเพล็ตสองประเภทที่มีรูปแบบความปลอดภัยที่แตกต่างกันมาก ได้แก่ แอปเพล็ตที่ลงนามและแอปเพล็ตที่ไม่ได้ลงนาม[ 32 ]เริ่มต้นด้วย Java SE 7 Update 21 (เมษายน 2013) แอปเพล็ตและแอป Web-Start ได้รับการสนับสนุนให้ลงนามด้วยใบรับรองที่เชื่อถือได้ และข้อความเตือนจะปรากฏขึ้นเมื่อเรียกใช้แอปเพล็ตที่ไม่ได้ลงนาม[ 33 ]นอกจากนี้ เริ่มต้นด้วย Java 7 Update 51 แอปเพล็ตที่ไม่ได้ลงนามจะถูกบล็อกโดยค่าเริ่มต้น สามารถเรียกใช้ได้โดยการสร้างข้อยกเว้นในแผงควบคุม Java [ 34 ]
ไม่มีลายเซ็น
ข้อจำกัดสำหรับแอปเพล็ตที่ไม่ได้ลงนามนั้นถูกมองว่า "เข้มงวดมาก" กล่าวคือ แอปเพล็ตเหล่านั้นไม่สามารถเข้าถึงระบบไฟล์ในเครื่องได้ และการเข้าถึงเว็บก็จำกัดอยู่เฉพาะเว็บไซต์ดาวน์โหลดแอปเพล็ตเท่านั้น นอกจากนี้ยังมีข้อจำกัดสำคัญอื่นๆ อีกมากมาย ตัวอย่างเช่นแอปเพล็ตเหล่านั้นไม่สามารถเข้าถึงคุณสมบัติของระบบทั้งหมด ไม่สามารถใช้คลาสโหลด เดอร์ของตนเอง เรียก ใช้ โค้ดเนทีฟเรียกใช้คำสั่งภายนอกบนระบบในเครื่อง หรือกำหนดนิยามใหม่ของคลาสที่อยู่ในแพ็กเกจหลักซึ่งเป็นส่วนหนึ่งของการเผยแพร่ Java ได้ แม้ว่าแอปเพล็ตเหล่านั้นจะสามารถทำงานในเฟรมแบบสแตนด์อโลนได้ แต่เฟรมดังกล่าวจะมีส่วนหัวที่ระบุว่านี่คือแอปเพล็ตที่ไม่น่าเชื่อถือ การเรียกใช้เมธอดที่ต้องห้ามสำเร็จในครั้งแรกไม่ได้สร้างช่องโหว่ด้านความปลอดภัยโดยอัตโนมัติ เนื่องจากตัวควบคุมการเข้าถึงจะตรวจสอบสแต็ก ทั้งหมด ของโค้ดที่เรียกใช้เพื่อให้แน่ใจว่าการเรียกใช้ไม่ได้มาจากตำแหน่งที่ไม่เหมาะสม
เช่นเดียวกับระบบที่ซับซ้อนใดๆ ก็ตาม ปัญหาด้านความปลอดภัยมากมายถูกค้นพบและแก้ไขไปแล้วนับตั้งแต่ Java เปิดตัวครั้งแรก บางปัญหา (เช่น บั๊กด้านความปลอดภัยในการเรียงลำดับข้อมูลปฏิทิน) ยังคงอยู่เป็นเวลาหลายปีโดยไม่มีใครรู้ ส่วนปัญหาอื่นๆ ถูกค้นพบว่าถูกนำไปใช้โดยมัลแวร์ที่แพร่ระบาดอยู่
บางการศึกษาได้กล่าวถึงแอปเพล็ตที่ทำให้เบราว์เซอร์ล่มหรือใช้ ทรัพยากร CPU มากเกินไป แต่สิ่งเหล่านี้ถูกจัดว่าเป็นเพียงปัญหาเล็กน้อย ไม่ใช่ช่องโหว่ด้านความปลอดภัยที่แท้จริง อย่างไรก็ตาม แอปเพล็ตที่ไม่ได้ลงนามอาจเกี่ยวข้องกับการโจมตีแบบผสมผสานที่ใช้ประโยชน์จากข้อผิดพลาดในการกำหนดค่าที่ร้ายแรงหลายอย่างในส่วนอื่นๆ ของระบบ แอปเพล็ตที่ไม่ได้ลงนามอาจเป็นอันตรายมากกว่าหากเรียกใช้โดยตรงบนเซิร์ฟเวอร์ที่โฮสต์อยู่ เพราะถึงแม้โค้ดจะอนุญาตให้สื่อสารกับเซิร์ฟเวอร์ได้ แต่การเรียกใช้ภายในเซิร์ฟเวอร์อาจหลีกเลี่ยงไฟร์วอลล์ได้ แอปเพล็ตอาจพยายามโจมตีแบบ DoSบนเซิร์ฟเวอร์ที่โฮสต์อยู่ แต่โดยปกติแล้วผู้ที่จัดการเว็บไซต์ก็จัดการแอปเพล็ตด้วย ทำให้การโจมตีแบบนี้เป็นไปไม่ได้ ชุมชนอาจแก้ไขปัญหานี้ได้โดยการตรวจสอบซอร์สโค้ดหรือเรียกใช้แอปเพล็ตบนโดเมนเฉพาะ
แอปเพล็ตที่ไม่ได้ลงนามอาจพยายามดาวน์โหลดมัลแวร์ที่โฮสต์อยู่บนเซิร์ฟเวอร์ต้นทาง อย่างไรก็ตาม มันสามารถจัดเก็บไฟล์ดังกล่าวไว้ในโฟลเดอร์ชั่วคราวเท่านั้น (เนื่องจากเป็นข้อมูลชั่วคราว) และไม่มีวิธีการใดที่จะทำการโจมตีให้สำเร็จโดยการเรียกใช้งานไฟล์นั้น เคยมีความพยายามที่จะใช้แอปเพล็ตเพื่อแพร่กระจายช่องโหว่ Phoenix และ Siberia ด้วยวิธีนี้แต่ช่องโหว่เหล่านี้ไม่ได้ใช้ Java ภายใน และยังถูกเผยแพร่ด้วยวิธีอื่นอีกหลายวิธี
ลงชื่อ
แอปเพล็ตที่ลงนาม[ 35 ]ประกอบด้วยลายเซ็นที่เบราว์เซอร์ควรตรวจสอบผ่านเซิร์ฟเวอร์หน่วยงานออกใบรับรอง อิสระที่ทำงานจากระยะไกล การสร้างลายเซ็นนี้เกี่ยวข้องกับเครื่องมือเฉพาะและการโต้ตอบกับผู้ดูแลเซิร์ฟเวอร์หน่วยงาน เมื่อลายเซ็นได้รับการตรวจสอบแล้ว และผู้ใช้เครื่องปัจจุบันอนุมัติ แอปเพล็ตที่ลงนามแล้วจะได้รับสิทธิ์มากขึ้น เทียบเท่ากับโปรแกรมแบบสแตนด์อโลนทั่วไป เหตุผลก็คือผู้เขียนแอปเพล็ตเป็นที่รู้จักแล้วและจะต้องรับผิดชอบต่อความเสียหายใดๆ ที่ตั้งใจทำ วิธีการนี้ช่วยให้แอปเพล็ตสามารถใช้สำหรับงานหลายอย่างที่ไม่สามารถทำได้โดยการเขียนสคริปต์ฝั่งไคลเอ็นต์ อย่างไรก็ตาม วิธีการนี้ต้องการความรับผิดชอบมากขึ้นจากผู้ใช้ในการตัดสินใจว่าตนไว้วางใจใคร ข้อกังวลที่เกี่ยวข้อง ได้แก่ เซิร์ฟเวอร์หน่วยงานที่ไม่ตอบสนอง การประเมินตัวตนของผู้ลงนามที่ไม่ถูกต้องเมื่อออกใบรับรอง และผู้เผยแพร่แอปเพล็ตที่เป็นที่รู้จักยังคงทำบางสิ่งที่ผู้ใช้ไม่เห็นด้วย ดังนั้นแอปเพล็ตที่ลงนามซึ่งปรากฏตั้งแต่ Java 1.1 อาจมีข้อกังวลด้านความปลอดภัยมากกว่า
ลงนามด้วยตนเอง
Self-signed applets, which are applets signed by the developer themselves, may potentially pose a security risk; java plugins provide a warning when requesting authorization for a self-signed applet, as the function and safety of the applet is guaranteed only by the developer itself, and has not been independently confirmed. Such self-signed certificates are usually only used during development prior to release where third-party confirmation of security is unimportant, but most applet developers will seek third-party signing to ensure that users trust the applet's safety.
Java security problems are not fundamentally different from similar problems of any client-side scripting platform[36]. In particular, all issues related to signed applets also apply to Microsoft ActiveX components.
As of 2014, self-signed and unsigned applets are no longer accepted by the commonly available Java plugins or Java Web Start. Consequently, developers who wish to deploy Java applets have no alternative but to acquire trusted certificates from commercial sources.
Alternatives
Alternative technologies exist (for example, WebAssembly[37] and JavaScript) that satisfy all or more of the scope of what was possible with an applet. JavaScript could coexist with applets in the same page, assist in launching applets (for instance, in a separate frame or providing platform workarounds) and later be called from the applet code. As JavaScript gained in features and performance, the support for and use of applets declined, until their eventual removal.
See also
ลิงก์ภายนอก
- Java Virtual Machine เวอร์ชันล่าสุดจาก Sun Microsystems (รวมถึงปลั๊กอินสำหรับเบราว์เซอร์เพื่อเรียกใช้ Java applet ในเบราว์เซอร์ส่วนใหญ่)
- ข้อมูลเกี่ยวกับการเขียนแอปเพล็ตจาก Oracle
- แอปเพล็ตสาธิตจาก Sun Microsystems ( JDK 1.4 –รวมซอร์สโค้ด)