Đang load dữ liệu
Cuối cùng Java 9 và bộ công cụ phát triển cho nó (Java Development Kit -JDK 9) cũng đã chính thức ra mắt người dùng và các nhà phát triển Java trên toàn thế giới.
Java 9 tuy có một số tính năng mới quan trọng tuy còn gây tranh cãi, nhưng đây là phiên bản cuối cùng trong chuỗi phát hành của Java 9.
Vậy bạn sẽ chuẩn bị những gì để tham gia vào cộng đồng phát triển Java trong những năm sắp tới?
Oracle đã đăng tải phiên bản này cùng các tài liệu cho phép các nhà phát triển tải về tại địa chỉ: http://jdk.java.net/9
Xuất hiện sau Java SE 8 tới gần ba năm, Java SE 9 có một vài thay đổi chủ chốt trong kiến trúc, cũng như hàng loạt cải tiến.
Khả năng mô-đun hóa – tính năng mới và gây tranh cãi, được dựa trên dự án Jigsaw, chắc chắn sẽ gây ra nhiều sự chú ý bởi của cả hai phe tiến bộ và bảo thủ.
Tính mô-đun – lấy chữ mô-đun trong “Java Platform Module System” – phân chia JDK thành một tập các mô-đun dành cho thực thi, biên dịch hoặc buid time. Đây được xem như một thay đổi xuyên suốt cho phép hiểu các phụ thuộc thông qua các mô-đun.
Tính mô-đun của Java 9 hỗ trợ các nhà phát triển dễ dàng tập hợp và bảo trì các ứng dụng phức tạp. Ngoài ra, nó cũng khiến Java trở nên tốt hơn trong việc thu nhỏ quy mô xuống các thiết bị nhỏ gọn trong khi vẫn cải thiện được bảo mật và hiệu suất.
Khía cạnh mô-đun của Java 9 thể hiện ở nhiều mặt, trong đó có cách đóng gói chương trình, sự mô-đun hóa bản thân JDK, và tổ chức mã nguồn thành các mô-đun. Hệ thống build được nâng cấp để biên dịch các mô-đun và duy trì ranh giới giữa các mô-đun trong lúc build. Các ảnh (chạy trong máy ảo Java) của JDK và JRE được tái cấu trúc để xử lý các mô-đun. Ngoài ra các thư viện JavaFX UI và các CSS API cũng được thay đổi để phù hợp với lối lập trình mới.
Tính mô-đun đi kèm với một loạt các cấu hình được hỗ trợ; dẫn tới sự cải thiện về khả năng mở rộng, bảo mật và hiệu suất của các ứng dụng. Mô-đun cũng giúp việc triển khai chương trình Java trên các thiết bị nhỏ trở nên dễ dàng hơn, đây là động lực chính trong nỗ lực đưa tính mô-đun vào Java.
Với tính mô-đun, các nhà phát triển sẽ có khả năng xây dựng và bảo trì các thư viện cũng như chương trình lớn cho cả Java SE cũng như Java EE. Tuy vậy, trong quá trình xây dựng Java 9, Oracle, IBM, Red Hat và một vài tổ chức đã có những bất đồng quan điểm lớn đối với sự thay đổi cơ bản trong nền tảng. Hệ thống mô-đun thật ra đã bị từ chối hồi Tháng 5, và chỉ được chấp thuận vào cuộc bỏ phiếu lần hai vào Tháng 6, sau khi dự án Java 9 đã được khởi động.
Ngay cả như thế, những tranh cãi vẫn tiếp diễn. Một số chuyên gia đã nói không với tính mô-đun, bất kể sự thực rằng Java 9 đã được phát hành.
Để giúp việc chuyển đổi mã nguồn cũ sang dạng mô-đun được dễ hơn, Java 9 cho phép truy cập trái phép những reflection trên class path, để JRE có thể tìm tới các lớp và tập tin tài nguyên. Mặc dù vậy, trình biên dịch sẽ đưa ra cảnh báo về những reflection này, và chúng sẽ không được hỗ trợ ở những phiên bản Java tiếp theo.
Dẫn đầu trong số những tính năng mới trong trình biên dịch của Java 9 là khả năng biên dịch trước (ahead-of-time compilation – AoT). Tính năng này vẫn đang trong giai đoạn thử nghiệm – nó cho phép các lớp của Java được biên dịch sang mã máy trước khi được gọi khởi chạy trong máy ảo. AoT compilation giúp cải thiện thời gian khởi động của tất cả các ứng dụng từ nhỏ đến lớn, trong khi ít hạn chế đến hiệu suất cao điểm.
Những trình biên dịch JIT (Just-in-time) hoạt động nhanh hơn, nhưng trong thực tế những chương trình Java hiện tại thường lớn tới mức mà phải mất một thời gian khá lâu để được biên dịch toàn bộ, hệ quả là trình biên dịch thường để lại một vài phương thức không được biên dịch, và dẫn tới giảm hiệu năng. AoT compilation được áp dụng là để giải quyết vấn đề này.
Thế nhưng Dmitry Leskov, giám đốc marketing của Excelsior – đối tác công nghệ Java, lo lắng rằng AoT chưa đủ trưởng thành và mong muốn Oracle đợi tới phiên bản Java tiếp theo cho tính năng này.
Oracle cũng triển khai giai đoạn hai của tính năng “biên dịch thông minh”, liên quan tới việc cải thiện tính ổn định và di động vào công cụ javac vì vậy nó có thể được sử dụng mặc định cho JVM (Java Virtual Machine). Công cụ này cũng được tổng quát hóa để có thể được dùng cho các dự án lớn vượt ra ngoài phạm vi của JDK. Ngoài ra, nó còn có thể biên dịch các chương trình được viết dưới Java 9 thành dạng có thể chạy trên những phiên bản Java cũ hơn.
Một tính năng mới khác cũng được đem vào triển khai thử nghiệm là JVMCI – Giao diện Biên dịch mức-Java cho JVM. Giao diện này cho phép một trình biên dịch được viết bằng Java có thể được dùng như một trình biên dịch động cho JVM. API của JVMCI cung cấp cơ chế để truy cập các cấu trúc của VM, cài đặt mã đã biên dịch và kết nối vào hệ thống biên dịch JVM. Nhờ đó các nhà phát triển có thể viết ra và sử dụng những trình biên dịch chất lượng cao và dễ dàng hơn trong việc bảo trì hay cải tiến các trình biên dịch hiện tại được viết bằng ngôn ngữ C hay C++. Hiện đã có một số nỗ lực được bỏ ra cho mục đích đó, như dự án Graal hay Metropolis.
Ngoài ra, trình biên dịch mới cũng cho phép các nhà phát triển điều khiển trình biên dịch theo ngữ cảnh ở từng phương thức, ngay tại thời điểm chạy, mà không ảnh hưởng tới hiệu năng. Công cụ cũng cho phép xử lý các lỗi trình biên dịch JVM.
Công cụ REPL đã quá quen thuộc với các nhà phát triển Ruby, Python, NodeJS… nhưng chưa bao giờ xuất hiện cho ngôn ngữ Java. Việc thiếu vắng REPL là một trong số những lý do các trường học từ chối sử dụng Java để giảng dạy. Nhà sáng lập của Scala – Martin Odersky đã từng đặt ra những câu hỏi tính hữu ích của một REPL, và ông đã phát biểu “Java thì hướng câu lệnh, trong khi đó các REPL thì hướng biểu thức”.
Nhờ những nỗ lực sau một dự án dài hơi, REPL cũng đã xuất hiện ở Java 9 dưới tên thương mại jShell. Ngoài khả năng tương tác với các câu lệnh khai báo và các biểu thức, giúp cho các nhà phát triển có thể nhận được phản hồi của một chương trình trước khi biên dịch chỉ bằng cách nhập vào một số dòng mã, jShell còn có thể hỗ trợ hoàn thiện câu lệnh/biểu thức và tự thêm những dấu chấm phẩy cần thiết. Nó cũng có một API để các IDE cũng như các công cụ khác có thể khai thác.
Các stream trong Java cho phép dữ liệu được khai thác song song một cách hiệu quả. Trong Java 9, Streams API được bổ sung những phương thức để lấy và cắt bỏ các phần tử từ Stream theo điều kiện, duyệt qua các phần tử của Stream, và tạo một stream từ một giá trị nullable.
Dự án Nashorn được theo đuổi để cung cấp một máy chạy Javascript cho Java, đã được cải tiến ở JDK 9. Nhiều nỗ lực đã được bỏ ra để Nashorn có hiệu năng cao nhưng vẫn đủ nhỏ. Nashorn cho phép nhà phát triển nhúng mã Javascript vào chương trình Java. Một Javascript REPL cũng đã đóng gói vào JDK.
Các phần được đóng gói còn có một API để giao tiếp với chương trình cây cú pháp ECMAScript của Nashorn, cho phép các công cụ cũng như IDE có thể phân tích mã Javascript mà không bị phụ thuộc vào chương trình thực thi của Nashorn.
HTTP/2 client API bản beta đã được bổ sung vào JDK 9, triểm khai những nâng cấp cho giao thức HTTP. Ở API này, WebSocket cũng đã được hỗ trợ.
API HTTP/2 client có thể thay thế cho API HttpURLConnection vốn có thể gặp sự cố, có nhiều giao thức không còn được hoạt động, quá trừu tượng, và khó sử dụng.
Trong JDK 9, công cụ tạo tài liệu Javadoc đã được cải tiến để tạo ra mã HTML5 cũng như hỗ trợ bảng mã Unicode 8.0, với nhiều ký tự và mã mới được bổ sung.
Cho mục đích bảo mật, Java 9 bổ sung API cho giao thức DTLS (Datagram Transport Layer Security). Giao thức này được thiết kế để ngăn chặn nghe trộm, giả mạo và ngụy tạo thông điệp trong giao tiếp giữa máy khách và máy chủ. API cho giao thức này cung cấp những giao diện để dùng cho cả máy khách lẫn máy chủ.
Java 9 ngưng sử dụng cũng như loại bỏ một số tính năng không còn phù hợp. Dẫn đầu trong số đó là API Applet, bị ngừng sử dụng, kéo theo đó là công cụ appletviewer. Hầu hết các nhà sản xuất trình duyệt hiện tại đều có ý thức loại bỏ sự hỗ trợ cho Java plugin. Thị trường đã chuyển sang sử dụng HTML và Java Web Start (để khởi chạy ứng dụng từ một trình duyệt).
Java 9 cũng ngưng sử dụng bộ dọn rác Concurrent Mark Sweep (CMS). Mục đích là để đẩy nhanh sự phát triển của các công cụ dọn rác trong máy ảo HotSpot. Một trong số đó là bộ dọn rác G1.
Đồng thời, các tổ hợp bộ dọn rác bị ngưng sử dụng ở Java 8 cũng được loại bỏ ở Java 9. Đa số là các tổ hợp hiếm khi sử dụng cũng như làm tăng độ phức tạp của việc dọn rác.
Java 9 cũng lược bớt những cảnh báo trên những lệnh import những thư viện bị ngưng sử dụng, để giúp các dự án lớn bớt đi các dòng cảnh báo khi chạy linter.
Ngoài ra, khả năng chọn JRE tại thời điểm thực thi cũng được loại bỏ. Tính năng này hiếm khi được sử dụng trong khi đó lại làm phức tạp việc khởi chạy chương trình, hơn nữa, nó cũng chưa bao giờ được cung cấp tài liệu đầy đủ kể từ khi xuất hiện lần đầu tiên trong JDK 5.
Oracle cũng đã loại bỏ hprof và jhat (những công cụ theo dõi và phân tích Heap) khỏi bộ công cụ JVM Tool Interface. Chúng đã lỗi thời cũng như đã được thay thế bởi những công cụ cao cấp hơn.
Kể từ sau Java 9, một chuỗi phát hành mới của Java sẽ được bắt đầu. Java sẽ được phát hành phiên bản mới sau mỗi sáu tháng, vào tháng 3 và tháng 9. Các đánh số phiên bản sẽ tương tự như cách mà Canonical sử dụng với Ubuntu – là sự kết hợp giữa 2 số cuối của năm phát hành và tháng phát hành phiên bản. Ví dụ, phiên bản đầu tiên của chuỗi phát hành này sẽ là Java 18.3, và phiên bản tiếp theo sẽ là Java 18.6.
Nhịp phát hành này cũng nói lên rằng Java 9 không được thiết kế để hỗ trợ dài hạn. Phiên bản LTS tiếp theo đã được ấn định sẽ là Java 18.9. Các nhà phát triển có thể bỏ qua Java 9 và các mô hình “chưa trưởng thành” của nó và chờ tới phiên bản mới.
Devmaster Academy via Tapchilaptrinh
.png "Lập trình frontend với reacjs (Full)")