Bới ngôn ngữ ra chuyện – tản mạn về JavaFX.
Độ này người của Sun đi đâu cũng khoe về JavaFX, nó như một tấm áo mới mặc mà đứa trẻ mặc vào đem đi khoe với bạn bè. Nghe nói và nghe nói, nhưng cũng chỉ là người của Sun nói chứ có mấy ai bới vào cái đống ngôn ngữ lộn xộn đó đâu. Rảnh rang một chút ngày mất điện, tôi rình mò để buôn chuyện trên blog này.
Posted by nhu dinh thuan
at 8:46 AM,
Read more
,
,
Back link
7 Comments :
Ngôn ngữ mới – học trong vài ngày là ok.Ừ, nó chẳng phải mới mẻ gì, ngẫm đi ngẫm lại thì nó cũng vay mượn cú pháp từ hàng loạt các language hay scripting thông dụng. SQL – Scripting Query Language là một ví dụ, nôm na nghe thiên hạ gọi là truy vấn, nghĩa là trong hàng đống dữ liệu được tổ chức trên đĩa cứng, viết các câu lệnh cho hệ quản trị truy và vấn ra ngoài. Scripting thì gần hơn với đời thường, có người dịch là thông dịch ngữ, kể cũng không sai. Bạn cứ tưởng tượng, bạn đang ở một cái cống vít kín bằng rác, đất và ... muốn thoát ra ngoài thì phải thông, đi đến đâu thì thông đến đó. Scripting chạy như vậy, nghĩa là đi đến đâu thì biên dịch tới đó, gặp lỗi trong runtime và ngữ pháp, dừng lại, phone cấp cứu cho lập trình viên. JavaScript là một ví dụ, vừa chạy vừa compile chứ không được compile trước rồi mới chạy sau như java. Điều đó có nghĩa là trong runtime, chúng ta có thể bị tuýt còi về mặt ngữ pháp ngoài song hành kết quả sai về logic cài đặt. Nhưng nếu đem cái nghĩa thông dịch ngữ vào JavaFX thì lại không đúng, nó phải dịch hết trước khi chạy. Một lỗi hỏng hóc về cú pháp là sẽ nhõng nhẽo với lập trình viên ngay. Từ đó mà suy luận, việc xây dựng JavaFX cũng không có gì quá phước tạp, một khi mà Java đã hỗ trợ cả compile với lớp Compiler từ Java 6. Trước đây có Bean Shell, Groovy, ... dù cũng là scripting nhưng chúng được xây dựng phức tạp hơn rất nhiều, nặng nề hơn rất nhiều mặc dù hiệu quả mang lại có thể cũng không hơn gì JavaFX.
Từ Java 6 , tốc độ chạy được cải thiện đến mức kinh ngạc, con số lên đến hàng chục phần trăm là điều có thể nghĩ tới, đặt biệt là với Swing. Tuy nhiên, bộ nhớ thì vẫn thế, không thể trách được vì mô hình lập trình hướng đối tượng là phải tốn kém về mặt bộ nhớ. Do đó, việc đẻ thêm JavaFX, luôn dịch lại trước khi chạy thì cũng chẳng hề hấn gì. Tốc độ lúc khởi động dù chậm hơn một tí nhưng trong runtime thì không sao. Nhưng cũng không hiểu vì sao mà bản thân version hiện tại của JavaFX lại không dịch một lần đầu duy nhất, sau đó file có sửa thì mới dịch lại,không sửa thì cứ lấy cái đã dịch ra mà chạy, làm như giải pháp JSP với Servlet class. Mỗi lần chạy chương trình, JavaFX chơi kiểu nông dân ăn chắc mặc bền là dịch lại toàn bộ rồi mới thong thả chạy chương trình. Đó là một điểm tồi của công nghệ này.
Lập trình giao diện bằng JavaFX rất đẹp? Xin thưa là JavaFX không vẽ lại các component đâu mà dùng ngay những gì Swing sẵn có. JavaFX chính là Swing đó, cái “ngôn ngữ” này là cách đơn giản hóa và đời thường hóa các thủ tục viết các ứng dụng Swing thông thường. Script thường được phịa ra để làm thủ tục giải quyết một nghiệp vụ nào đó, và JavaFX cũng như vậy. Nó tập trung vào giao diện, nghĩa là trên bề mặt, miễn sao cho lập trình viên cảm thấy gần gũi, dễ dàng, nhanh chóng và thoải mái, đặc biệt là cái khâu căn chỉnh, hiệu chỉnh trên giao diện đồ họa. Về mặt ngôn ngữ, nó cũng được thiết kế để tập trung cho mục đích này, chẳng hạn ví xem đoạn lệnh đưới đây, đố bạn biết kết quả sẽ là gì?
var n = [11, 33, 51, 7, 3, -11];
var x = select i from i in n where i%2 == 0;
System.out.println(x);
Hãy nhắn tin đến số 1900 một không không rõ để trả lời cho chương trình và dự đoán số người có cùng kết quả với bạn. Phần thưởng là một trình nghe nhạc miễn phí từ JavaFX sẽ được gửi đến bạn.
Thông thường thì với những kết quả x trả về như vậy, lập trình viên sẽ phải viết các if-else để hiển thị trên giao diện người dùng sao cho hợp lý nhất. Với JavaFX thì không phải lo lắng nhiều về việc đó, nó là scripting cơ mà, nó sẽ giúp bạn đưa ra một kết quả hợp tình vào trường hợp này. Một lời khuyên là với những nghiệp vụ phức tạp đòi hỏi tính chính xác trong logic cài đặt, đừng bao giờ chọn scripting.
Và những thứ không cần thiết, chẳng hạn như việc JavaFX cho phép đặt tên biết phải trùng với từ khóa nhưng phải có 4 ngoặc nhọn ở hai đầu, chẳng hạn var <<if>>. Câu lệnh truy vấn tương đối dài dòng như insert, delete, statement,... mặc dù chúng mang lại ý nghĩa rõ ràng và gần gũi hơn. Khai báo bước nhảy với mảng, chẳng hạn [1, 4, 13] kết quả giá trị sẽ là [1, 4, 7, 10, 13], bước nhảy 4 - 1 = 3.
Bản thân JavaFX hiện tại không nhẹ nhàng, tới 2.24mb với 3 tập tin nén. Đó là những thứ cần thiết để chạy JavaFX ngoài JRE cần phải cài đặt. Điều mong chờ lớn nhất hiện lại là việc Sun sẽ tung ra Cumtomer JRE, một phiên bản JRE nặng chỉ khoảng 2-3mb với một số module cơ bản. Sau đó, nếu cần gì thì JRE mới tự động lấy về từ mạng (copy ý tưởng từ maven). Đó cũng là một cách hay để trợ giúp các ứng dụng Java tích hợp JRE vào, khỏi cần phải bắt người dùng cài đặt. Nhưng với JavaFX, các gói trên vẫn phải đi kèm để nó có thể làm việc được, phần lớn code trong JavaFX chỉ là định nghĩa lại các component của Swing cùng layout trong JDK 5 trở đi. Quá nặng cho một giải pháp dựa dẫm vào Swing với hơn 2mb. Chúng ta mong chờ vào sự cải tiến này.
JavaFX thực chất chỉ là ứng dụng Java nhận đầu vào là một FX file (tập tin có đuôi FX). Tập tin này được soạn thảo tuân thủ các cú pháp của JavaFX, cú pháp này mang nhiều đặc điểm của một scripting. Câu lệnh chạy một ứng dụng FX thực chất là như sau: java net.java.javafx.FXShell VarExample.fx. Đó, không có gì là cao xa cả, những gì mà JavaFX làm được thì Rhino của Mozilla đã làm được rồi. Sau này Rhino đã tích hợp vào Java 1.6 trở đi. Rhino thực chất là một công nghệ giúp JVM hiểu được ngữ pháp của JavaScript. Chúng ta có thể xây dựng các ứng dụng có giao diện là Swing trong một file scripting có ngữ pháp giống như JavaScript. Tuy nhiên, tập lệnh JavaScript hiểu được ở Rhino có thể khác với những gì mà trình duyệt đọc cú pháp của các scripting dành cho HTML. Rhino sẽ không thể hiểu được các thành phần của HTML DOM là gì? Chúng được tạo ở đâu? Khi nào? Dĩ nhiên giải quyết vấn đề này đã có một vài dự án làm, tập trung cho các xử lý giống như trình duyệt xử lý với tài liệu HTML, nhưng chưa được thành công mỹ mãn. JavaScript ở đây cũng giống như FX, đóng vai trò như một cú pháp mới và JVM có thể hiểu được qua công nghệ nào đó.
Nếu FX thành công, điều đó có thể đem lại sự trở về của Applet, bởi FX chỉ là text. Do đó, không nhất thiết phải load toàn bộ về phía client, một khi đã làm được như vậy thì mô hình xử lý của AJAX đem lại cho trình duyệt cũng có thể cài đặt vào các ứng dụng FX. Linh động hơn, FX có cú pháp rõ ràng và chặt chẽ, hơn nữa, một tài nguyên đồ sộ các thư viện từ Java có thể được tận dụng tối đa. Nhưng vẫn còn phải chờ đợi, vì biết đâu FX không sẽ mang lại thành công như người ta mong muốn. Trong kỷ nguyên Web, bản thân HTML và JavaScript đã dần bộc lộ yếu điểm và không thể đảm đương những đòi hỏi của thị trường. Hoặc là HTML + JavaScript sẽ phải được thiết kế tốt hơn, hoặc sẽ có một giải pháp thay thế. Nhưng câu hỏi như: Cái nào? Khi nào? thì cũng chưa ai trả lời được. Chẳng hạn, hồi mới XML và XSLT mới được người ta biết đến nhiều, ai đó đã nghĩ rằng nó sẽ thay thế được HTML, nhưng đến tận giờ nó vẫn không thể thay thế được bởi cú pháp của XSLT quá rắc rối. Còn FX, liệu có đủ mạnh để thành công?
Anh có thể viết bài hướng dẫn về cách thực thi javafx được không ạ? Cụ thể là dùng java web start và applet.
Cám ơn những bài viết về javafx của anh rất nhiều
anh đã đề cập ở một seminar về vấn đề này. Sau khi JRE 6uN ra mắt vào khoảng mùa hè này sẽ có những series bài viết về JavaFX.
Ngoài việc hỗ trợ một cú pháp mới cho việc phát triển giao diện, JavaFX còn có lợi điểm nào so với Java bình thường không anh? Vì em thấy nhưng gì javafx làm được chúng ta đều có thể làm với ngôn ngữ java thông thường.
anh chưa có một thống kê hay một phân tích chính xác nào lợi điểm của JavaFX nhưng theo logic, anh cũng xin nêu ra một số đặc điểm:
- JavaFX là một scripting nửa vời, nó mang tất cả những ưu thế về mặt ngôn ngữ của scripting như dễ viết, ngắn gọn, gần hơn với đời sống thực. Xét về tổng quan nhé.
- JavaFX hướng đến RIA - Rich Internet Application. Do vậy, nếu truyền một text file đi trên Internet sẽ nhẹ hơn nhiều so với truyền một class. Thông thường, các .class sẽ nặng hơn file .java. Dùng thêm các kỹ thuật nén nữa thì quá tuyệt vời vì các thuật toán nén thể hiện thế mạnh vượt trội ở dữ liệu text.
- JavaFX có thể hướng đến những đối tượng không chuyên về lập trình như designer bởi dễ viết, dịch lúc chạy (làm giao diện tiện hơn),... Tạo được một cộng đồng designer mạnh mẽ giống như Flash thì quá tuyệt vời với Java.
Anh đã thử nghiệm customer jre bản build 10 mới nhất. Những thiết kế lại để hướng đến RIA của Sun cho thấy tốc độ đã trở nên quá kinh ngạc. Java 6 đã làm một bước tiến dài về tốc độ nhưng Customer JRE lại là một bước tiến nữa. Từ giờ thì đừng nói rằng Java chậm. Nếu ai đó còn nói về yếu điểm đó của Java thì có lẽ họ đã là cố nhân đang sống ở thiên nên kỷ trước.
Tuy nhiên do là một nền tảng lập trình hướng đối tượng nên bộ nhớ của ứng dụng vẫn khá lớn. Nó không phải là rào cản với phần cứng rẻ ở thời hiện tại. Customer JRE cần được thiết kế đủ nhỏ khoảng 1-2mb là đẹp nhất, có thể cắm vào trình duyệt như một plugin. Các ứng dụng sẽ được renderer bằng Java thay vì dùng renderer dành cho HTML của trình duyệt. Hệ thống thư viện trong JRE cũng cần độc lập và được loại bỏ bớt, khi ứng dụng nào cần mới lấy về. Mô hình này học hỏi từ maven (build ứng dụng).
Anh sẽ cố gắng có một bài viết tiếp theo về JavaFX và sẽ đề cập đến những mặt mạnh - yếu của nó trên blog.
Cám ơn anh. Nhưng về gạch đầu dòng thứ 2 của anh (tức là việc truyền file text trên mạng), theo em sẽ không xảy ra vì hiện nay đã có JavaFX Compiler dùng để biên dịch file fx sang file class nhằm tăng tốc độ của ứng dụng JavaFX. Không cần dùng tới class net.java.javafx.FXShell để thông dịch file fx khi runtime nữa nữa.
cao nhan. Viet hay lam
Comment as Anonymous if you don't have Google accounts
Post a Comment
Home