Java AWT và SWING

1. Tổng quan

A. Khái niệm

AWT (Abstract Window Toolkit) và SWING là thư viện chuẩn để hiện thực GUI (giao diện đồ họa người dùng) trong Java. AWT là cách tiếp cận ban đầu phụ thuộc vào thành phần gốc (native) của hệ điều hành (hạng nặng, heavyweight), còn SWING là cách tiếp cận kế tiếp trong đó Java tự vẽ màn hình để nâng cao tính độc lập nền tảng (hạng nhẹ, lightweight).

Lý do căn bản để so sánh song song hai thư viện nằm ở câu hỏi 'làm thế nào hiện thực lý tưởng độc lập nền tảng của Java (Write Once, Run Anywhere, WORA) trong lĩnh vực phụ thuộc hệ điều hành nhiều nhất là GUI'. Logic máy chủ · tính toán được chuyển đổi không mấy khó khăn nhờ bytecode JVM, nhưng những phần gắn với màn hình và thiết bị nhập như cửa sổ (Window) · nút · phông chữ · sự kiện chuột thì cách cài đặt khác nhau rất lớn giữa các hệ điều hành, nên 'viết một lần, chạy như nhau ở mọi nơi' là điểm khó giữ nhất. Khác biệt thiết kế giữa AWT và SWING chính là lời giải của hai thế hệ giải quyết khó khăn này theo những cách khác nhau.

AWT ban đầu (JDK 1.0, 1996) chọn cách lấy nguyên các thành phần GUI gốc mà mỗi hệ điều hành đã cung cấp sẵn (nút của Windows, cửa sổ của X Window v.v.) để sử dụng. Một java.awt.Button trong mã Java thực chất được ánh xạ 1:1 tới một nút thật tồn tại trong hệ điều hành (peer - đối tác). Cách này dùng nguyên widget đã được hệ điều hành tối ưu nên vẽ nhanh và có được hình dạng quen thuộc đặc trưng của hệ điều hành, nhưng chính vì hình dạng · kích thước · hành vi của thành phần mỗi hệ điều hành một khác nên màn hình khác nhau theo nền tảng, và chỉ có thể dùng 'mẫu số chung nhỏ nhất' của các widget mà mọi hệ điều hành cùng có, khiến khả năng biểu đạt bị hạn chế nhiều. Điều này đi ngược trực diện với lý tưởng 'giống nhau ở mọi nơi' mà Java đề cao.

Thứ cải thiện hạn chế này là SWING (JDK 1.2, 1998, một phần của JFC). SWING không phụ thuộc vào widget gốc của hệ điều hành mà Java tự vẽ từng điểm ảnh. Chỉ cửa sổ cấp cao nhất (JFrame · JDialog) gắn với tài nguyên hệ điều hành (peer), còn các thành phần bên trong như nút · bảng · cây đều là hình vẽ do Java vẽ. Nhờ đó bảo đảm hình dạng · hành vi giống nhau trên mọi hệ điều hành, và cung cấp các thành phần phong phú như bảng (JTable) · cây (JTree) · thẻ (JTabbedPane) cùng khả năng thay đổi tự do Look and Feel (giao diện và cảm nhận). Tuy nhiên, vì Java tự vẽ nên ở giai đoạn đầu ra đời (cuối thập niên 1990 ~ đầu thập niên 2000), khi hiệu năng phần cứng còn thấp, nó từng bị đánh giá là 'nặng và chậm'. Tóm lại, sự phát triển từ AWT sang SWING được tóm gọn là quá trình thoát khỏi phụ thuộc gốc để theo đuổi GUI độc lập nền tảng thực sự.

B. Bối cảnh xuất hiện và sự cần thiết

Căng thẳng bản chất mà một framework GUI phải giải quyết là 'thân thiện gốc (nhanh · diện mạo chuẩn của hệ điều hành) đối lập với nhất quán nền tảng (diện mạo giống nhau · biểu đạt phong phú)'. AWT chọn vế trước và đánh mất vế sau, còn SWING từ bỏ một phần vế trước để có vế sau. Sự đánh đổi này là chủ đề thường trực của thiết kế GUI, lặp lại ngay cả ở các framework đa nền tảng ngày nay (Electron, Flutter, React Native), và vì thế sự đối lập AWT/SWING thường xuất hiện trong đề thi không phải như kiến thức cú pháp Java đơn thuần mà như chất liệu để hiểu 'nguyên mẫu (archetype) của lựa chọn kiến trúc GUI'.

2. Kiến trúc — Thành phần hạng nhẹ vs hạng nặng

Cốt lõi kỹ thuật phân biệt AWT và SWING là việc thành phần có được ánh xạ tới tài nguyên hệ điều hành hay không, tức sự phân biệt hạng nặng (heavyweight) và hạng nhẹ (lightweight). Sơ đồ cấu trúc dưới đây đối chiếu hai cách đặt trách nhiệm vẽ ở đâu giữa ứng dụng · JVM · hệ điều hành.

flowchart TB
  APP["Ứng dụng GUI Java"]
  subgraph AWTPATH["Đường AWT (hạng nặng)"]
    AWTC["java.awt.Button v.v."] --> PEER["Peer gốc"]
    PEER --> OSW["Widget gốc của hệ điều hành"]
  end
  subgraph SWINGPATH["Đường SWING (hạng nhẹ)"]
    JC["javax.swing.JButton v.v."] --> J2D["Bộ máy vẽ Java2D"]
    J2D --> TOP["Container cấp cao nhất (JFrame)"]
    TOP --> OSTOP["Cửa sổ hệ điều hành (1 peer)"]
  end
  APP --> AWTC
  APP --> JC
  style SWINGPATH fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px

Thành phần hạng nặng (AWT) — mỗi thành phần chiếm một tài nguyên gốc của hệ điều hành, tức một peer. Tạo 100 nút đồng nghĩa với sinh ra 100 widget của hệ điều hành. Cách này để hệ điều hành xử lý thay việc vẽ · sự kiện nên gánh nặng phía Java nhỏ và phản hồi nhanh, nhưng tiêu tốn nhiều tài nguyên hệ điều hành là peer và hành vi khác nhau theo hệ điều hành. Ngoài ra, thành phần hạng nặng luôn được vẽ đè lên trên thành phần hạng nhẹ — vấn đề 'chồng lấn thứ tự Z' — nên khi trộn AWT với SWING từng xảy ra hiện tượng menu bị thành phần khác che mất.

Thành phần hạng nhẹ (SWING) không có tài nguyên hệ điều hành riêng, mà Java vẽ trực tiếp lên vùng màn hình của container hạng nặng cấp cao nhất chứa nó (JFrame v.v.). Dù có bao nhiêu thành phần, cửa sổ hệ điều hành thực tế chỉ là vài cái cấp cao nhất nên hiệu suất tài nguyên tốt, và vì Java kiểm soát mọi việc vẽ nên tạo ra màn hình hoàn toàn giống nhau bất kể hệ điều hành. Những biểu đạt khó làm với widget gốc như vùng trong suốt · góc bo tròn · tự vẽ tùy biến cũng được tự do. Nguyên tắc 'Java vẽ tất cả' này là cội nguồn của tính độc lập nền tảng và khả năng biểu đạt phong phú của SWING.

3. Cấu trúc MVC và pipeline vẽ

Một điểm mạnh thiết kế khác của SWING là mỗi thành phần được xây dựng theo cấu trúc biến thể MVC (Model-View-Controller). Chẳng hạn, JTable tách riêng mô hình chứa dữ liệu (TableModel), khung nhìn đảm nhận biểu diễn màn hình (renderer/UI Delegate) và bộ điều khiển đảm nhận chỉnh sửa · tương tác. Sơ đồ dưới đây thể hiện quá trình đầu vào của người dùng đi qua luồng điều phối sự kiện (EDT) để cập nhật mô hình · khung nhìn và phản ánh lên màn hình.

sequenceDiagram
  participant U as Người dùng
  participant EDT as Luồng điều phối sự kiện(EDT)
  participant M as Mô hình(TableModel v.v.)
  participant V as UI Delegate(khung nhìn)
  U->>EDT: Sự kiện nhấp chuột/nhập phím
  EDT->>M: Yêu cầu thay đổi trạng thái mô hình
  M-->>EDT: Thông báo thay đổi(Listener)
  EDT->>V: Lên lịch repaint()
  V->>V: Vẽ lại bằng paintComponent()
  V-->>U: Hiển thị màn hình đã cập nhật

Ý nghĩa thực tiễn của việc tách mô hình-khung nhìn thể hiện rõ ở những màn hình xử lý dữ liệu lớn. Khi vẽ bảng hàng chục nghìn dòng, mô hình chỉ giữ dữ liệu còn khung nhìn chỉ vẽ phần hiển thị trên màn hình, nên tiết kiệm được bộ nhớ · hiệu năng. Việc nhiều khung nhìn dùng chung một mô hình, hay chỉ đổi Look and Feel để khoác diện mạo khác, cũng là nhờ sự tách biệt này. Đây là cùng nguyên lý với việc tách trạng thái-khung nhìn của frontend ngày nay (React v.v.), cho thấy SWING đã chọn một thiết kế đi trước thời đại.

Quy tắc luồng điều phối sự kiện (EDT) là điểm hay mắc lỗi nhất khi phát triển SWING. Các thành phần SWING không an toàn luồng (thread-safe), nên mọi cập nhật UI bắt buộc phải thực hiện trên EDT — một luồng duy nhất. Nếu chạy tác vụ tốn thời gian (I/O tệp · mạng) trên EDT, màn hình sẽ đứng (freeze), nên mẫu chuẩn là dùng SwingWorker xử lý ở luồng nền rồi chỉ chuyển kết quả sang EDT để cập nhật màn hình. Vi phạm quy tắc này sẽ gây lỗi vẽ chập chờn hoặc bế tắc (deadlock), và mô hình 'một luồng UI duy nhất' này về sau trở thành nguyên tắc chung mà hầu hết các framework GUI cùng chia sẻ.

Look and Feel có thể cắm ghép (Pluggable Look & Feel) là chức năng biểu tượng của SWING. Chỉ với một dòng UIManager.setLookAndFeel(...) có thể thay đổi toàn bộ diện mạo sang Metal (mặc định của Java), Nimbus, hay System L&F bắt chước từng hệ điều hành. Điều này khả thi vì Java tự vẽ, mang lại sự linh hoạt "cùng một mã nhưng mô phỏng cảm giác gốc của từng hệ điều hành, và khi cần thì có diện mạo thống nhất hoàn toàn".

4. So sánh AWT vs SWING và tình huống thực tế

Hai thư viện không phải quan hệ thay thế mà là quan hệ kế thừa · mở rộng. SWING không vứt bỏ AWT, mà tái sử dụng nguyên hạ tầng nền tảng của AWT như mô hình xử lý sự kiện (mô hình sự kiện ủy quyền, Delegation Event Model) · trình quản lý bố cục (BorderLayout · GridLayout v.v.) · đồ họa (Graphics) · màu sắc, và chỉ làm lại tầng thành phần theo kiểu hạng nhẹ. Vì vậy, ngay cả khi viết ứng dụng SWING vẫn import và dùng kèm các lớp bố cục và sự kiện của java.awt.*. Sự thật này là điểm then chốt sửa lại hiểu lầm phổ biến rằng "SWING đã thay thế hoàn toàn AWT".

flowchart LR
  AWT["AWT<br/>(phụ thuộc thành phần hệ điều hành)"] --> OS["Diện mạo khác nhau theo hệ điều hành"]
  SWING["SWING<br/>(Java tự vẽ)"] --> UNI["Diện mạo giống nhau trên mọi hệ điều hành"]
  AWT -.tái sử dụng nền tảng.-> SWING
  style SWING fill:#e8f0fe,stroke:#2f6fed

Nhìn qua các tình huống cụ thể thì khác biệt sẽ rõ ràng. Thứ nhất, so sánh môi trường phát triển tích hợp (IDE) IntelliJ IDEA với dòng Eclipse trước đây: IntelliJ dựa trên SWING nên cung cấp màn hình gần như giống nhau trên mọi hệ điều hành, còn Eclipse dựa trên SWT/JFace dùng widget gốc nên diện mạo khác nhau theo hệ điều hành — đây là tình huống tiêu biểu cho thấy ngay trong cùng cộng đồng Java, lựa chọn 'nhất quán vs gốc' cũng đã rẽ đôi. Thứ hai, các client giao dịch nội bộ · hệ thống tài khoản lõi của ngành tài chính và nhiều bảng điều khiển quản trị doanh nghiệp được xây dựng hàng loạt bằng SWING (hiển thị dữ liệu lớn bằng JTable) vào những năm 2000 và đến nay vẫn đang được bảo trì. Thứ ba, các công cụ quản trị cơ sở dữ liệu · trình cài đặt của Oracle cũng được viết bằng SWING và chạy giống nhau trên Windows · Linux · Mac. Như vậy, giá trị của SWING rất lớn ở các công cụ · hệ thống nội bộ cần 'triển khai trên nhiều hệ điều hành nhưng thống nhất màn hình'.

5. Chuyên sâu — Tiến hóa sang JavaFX và vị trí hiện đại

Thế hệ nối tiếp AWT · SWING là JavaFX (công bố lần đầu năm 2008, trở thành API Java từ JavaFX 2.0). JavaFX cải thiện hạn chế của SWING ở nhiều mặt. Thứ nhất, với kiến trúc dựa trên đồ thị cảnh (Scene Graph), màn hình được xử lý như các đối tượng có cấu trúc cây, hỗ trợ tự nhiên hoạt ảnh · hiệu ứng · biến đổi. Thứ hai, đưa vào định kiểu bằng CSS và FXML (ngôn ngữ đánh dấu UI khai báo) để tách thiết kế khỏi logic và cung cấp cách làm quen thuộc với lập trình viên web. Thứ ba, xử lý đa phương tiện phong phú · biểu đồ · 3D bằng pipeline vẽ tăng tốc GPU (Prism). JavaFX cũng tích hợp sẵn chức năng liên kết dữ liệu (Property/Binding), hỗ trợ đồng bộ mô hình-khung nhìn ở mức ngôn ngữ.

Thay đổi đáng chú ý là từ JDK 11 (2018), JavaFX được tách khỏi JDK và phân phối dưới dạng mô-đun riêng (OpenJFX). Tức là Oracle đã tách JavaFX khỏi JDK lõi và chuyển giao cho cộng đồng mã nguồn mở (Gluon v.v.) dẫn dắt, và giờ đây JavaFX được thêm vào dưới dạng phụ thuộc Maven/Gradle. Ngược lại, AWT và SWING vẫn nằm trong JDK chuẩn, và Oracle duy trì chúng như di sản ổn định 'không có kế hoạch loại bỏ'. Nghịch lý là thế hệ kế tiếp JavaFX lại bị tách khỏi lõi còn SWING cũ vẫn ở lại, nên trong thực tế SWING vẫn thường giữ vị trí mặc định của ứng dụng desktop Java.

Mặt khác, trong dòng chảy rộng hơn, trọng tâm của GUI đã dịch chuyển từ desktop sang web · di động. Ngày nay các ứng dụng mới được làm bằng trình duyệt (SPA) · ứng dụng di động · framework đa nền tảng như Electron/Flutter, và tỷ lệ chọn mới GUI desktop Java đã giảm. Dù vậy, trong lĩnh vực UI của thiết bị điều khiển · đo lường công nghiệp, công cụ nội bộ của ngành tài chính · khu vực công, và bảo trì các tài sản SWING quy mô lớn đã được xây dựng, AWT · SWING vẫn tiếp tục được sử dụng tích cực.

6. Những điểm cần cân nhắc và hàm ý

Dưới góc nhìn Kỹ sư chuyên nghiệp (Professional Engineer), AWT · SWING cần được đọc như lăng kính của việc ra quyết định kiến trúc GUI, vượt ra ngoài kiến thức về một thư viện đơn lẻ.

1. Đánh đổi giữa độc lập nền tảng và hiệu năng · thân thiện gốc. AWT là gốc nên nhanh và có diện mạo chuẩn hệ điều hành nhưng mất tính nhất quán và khả năng biểu đạt, còn SWING có được tính nhất quán · biểu đạt phong phú nhưng phải gánh chi phí vẽ. Sự đối lập này lặp lại nguyên vẹn trong lựa chọn Electron (nhất quán nhờ công nghệ web, bộ nhớ nặng) · Flutter (nhất quán nhờ tự vẽ) · React Native (thân thiện nhờ widget gốc) ngày nay, nên khi quyết định ngăn xếp GUI cho dự án mới nhất thiết phải cân nhắc.

2. Bảo trì di sản và chiến lược hiện đại hóa. Khá nhiều client doanh nghiệp Java được viết bằng SWING và vẫn đang vận hành. Khi xử lý chúng, cần chọn giữa (a) tiếp tục bảo trì, (b) chuyển dần sang JavaFX, (c) xây dựng lại thành web (SPA) · client nhẹ, có xét đến nhân lực · tuổi thọ · chi phí của tổ chức. Nếu không biết các nguyên tắc như quy tắc EDT · SwingWorker thì dễ tạo ra lỗi tinh vi trong quá trình hiện đại hóa.

3. Tính phổ quát của mô hình một luồng UI. Quy tắc EDT của SWING (mọi cập nhật UI trên một luồng, tác vụ nặng chuyển xuống nền) về sau trở thành nguyên tắc chung mà hầu hết các framework GUI cùng chia sẻ. Hiểu chính xác khái niệm này thì dù chuyển sang framework khác vẫn có thể áp dụng nhất quán thiết kế về độ phản hồi UI · đồng thời.

4. Tính tiên phong của tách kiến trúc (MVC). Việc tách mô hình-khung nhìn của SWING là ví dụ hiện thực trước tư tưởng tách trạng thái-khung nhìn của frontend ngày nay. Nguyên tắc thiết kế tách dữ liệu · biểu diễn · tương tác là tài sản được giữ lại dù framework thay đổi, nên cảm quan thiết kế có được qua việc học di sản có thể chuyển giao sang ngăn xếp mới.

5. Góc nhìn quản lý rủi ro về việc có nằm trong chuẩn hay không. Việc JavaFX bị tách khỏi JDK (JDK 11) và cần quản lý phụ thuộc riêng, trong khi SWING/AWT vẫn ở lại trong lõi, cho thấy khi lựa chọn công nghệ, 'hỗ trợ dài hạn của nhà cung cấp · có nằm trong chuẩn hay không' là tiêu chí phán đoán quan trọng ngang với hiệu năng · chức năng.

Tài liệu tham khảo

• Oracle, "The Swing Tutorial (The Java Tutorials)" — https://docs.oracle.com/javase/tutorial/uiswing/
• Oracle, "AWT (java.awt) API Documentation" — https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/java/awt/package-summary.html
• OpenJFX, "JavaFX — Getting Started / Modular distribution" — https://openjfx.io/

Tóm tắt một câu: AWT là GUI hạng nặng phụ thuộc thành phần gốc của hệ điều hành, SWING là GUI hạng nhẹ do Java tự vẽ bằng Java2D, cung cấp tính độc lập nền tảng · thành phần phong phú · tách MVC · thay đổi Look and Feel, được mở rộng trên nền AWT để vượt qua hạn chế; sau đó tiếp nối bằng JavaFX với đồ thị cảnh · CSS · tăng tốc GPU, nhưng SWING/AWT vẫn ở lại trong JDK chuẩn và tiếp tục được dùng tích cực cho hệ thống di sản · công cụ nội bộ.