Bạn có bắt đầu di chuyển dự án Swing của mình sang JavaFX [đã đóng]

Tôi có một dự án 4 năm tuổi được viết bằng Swing + SwingX. Hiện tại, nó vẫn còn sống và vẫn còn đá.

Tuy nhiên, khi có nhiều yêu cầu tính năng liên quan đến GUI xuất hiện (Ví dụ: bảng cây có thể sắp xếp), tôi bắt đầu cảm thấy khó khăn trong việc điền đầy đủ các yêu cầu. Điều này đặc biệt đúng vì không có bất kỳ sự phát triển tích cực nào xung quanh dự án SwingX.

Ngoài ra, tôi khó có thể tìm thấy bất kỳ khung công tác GUI GUI tốt, nhưng được duy trì / phát triển / tích cực.

Tôi đã tự hỏi, có ai trong số các nhà phát triển Swing cảm thấy điều tương tự không? Bạn đã bắt đầu di chuyển dự án Swing của mình sang khung GUI được phát triển tích cực hơn nhiều, như JavaFX chưa?

Cá nhân tôi đang chuyển sang JavaFX (2.1+, không phải phiên bản 1.x kỳ lạ cũ với ngôn ngữ kịch bản khó chịu). JavaFX mới không hoàn hảo 100%, nhưng nó đã trở nên dễ sử dụng hơn so với Swing, tôi thấy một tương lai hợp lý cho nó (đặc biệt là với công cụ Webkit nhúng).

Tôi thường tự hỏi mình điều tương tự, nhưng tôi không nghĩ mình sẽ chuyển các dự án hiện có sang JavaFX. Ít nhất là không phải bây giờ, và không phải cho các dự án cỡ vừa đến lớn. Tuy nhiên, tôi sẽ xem xét JavaFX cho các dự án mới và xem xét lại việc di chuyển trong tương lai và đánh giá lại câu hỏi dựa trên tiến trình của JavaFX.

Hiện tại, mối quan tâm của tôi là:

• Sự non nớt

  Vâng, chúng tôi sẽ sớm lên 3.0, nhưng nó đã không tồn tại lâu như vậy và vẫn trải qua những thay đổi lớn. Vì vậy, đối với phần mềm doanh nghiệp lớn và không thích rủi ro, đây là một điểm tương đối nhức nhối.

• Hiệu suất

  Tôi chưa thấy đủ dữ liệu cứng về hiệu suất.

• Widgets và các thành phần

  Tôi chưa thấy đủ lợi ích trong các thành phần mới. Điều này có thể liên quan đến sự non nớt, tôi đoán vậy. Tôi cũng không biết chúng có thể được mở rộng và kết hợp tốt như thế nào, trái ngược với Swing.

Nhìn chung, tôi đoán dữ liệu cứng về các ưu điểm là những gì tôi thiếu để được thuyết phục hoàn toàn bởi JavaFX.

Mặt khác, Swing được chứng minh và thử nghiệm. Đúng, API rất rắc rối và gọi tự động hoàn thành trong IDE của bạn trên một đối tượng Swing như JTextPane sẽ khiến nó khóc và khóc cho mẹ của nó, nhưng, nếu bạn đủ hiểu biết, bạn có thể xây dựng các UI tuyệt vời với Swing, điều đó đang hoạt động tốt (tôi chưa bao giờ mua ngụy biện hiệu suất của Swing, xem các bài đăng trên blog cũ của Romain Guy trên blog của Sun) và cho phép bạn làm những việc khá gọn gàng.

Vì vậy, trước khi chuyển đổi bất cứ điều gì, tôi khuyên bạn nên thử một nguyên mẫu nhỏ trước và có thể thử chuyển một số hộp thoại của ứng dụng của bạn và xem nó hoạt động như thế nào.

Bây giờ tôi đã làm rất nhiều JavaFX và tôi thích nó hơn Swing. Cấu trúc Biểu đồ cảnh khác với cấu trúc bạn đã sử dụng với Xoay, nhưng nó cung cấp rất nhiều cải tiến. API rất thú vị khi làm việc với nó, nó cảm thấy mới mẻ.

Có rất nhiều thứ bạn có thể làm với nó, đa phương tiện, hoạt hình, duyệt web. Ví dụ, bạn có thể xây dựng một ứng dụng Google Maps trong một vài dòng mã, nhúng html5 và javascript.

Nó được cho là được bao gồm trong thời gian chạy Java 8, có nghĩa là sự thay thế xác định của Swing làm khung ui mặc định

@ Di chuyển : Bạn nên bắt đầu bằng cách cách ly các phần trong ứng dụng của bạn có thể được chuyển đổi thành JavaFX. Khả năng tương tác của Swing-JavaFX 2 là một điều tuyệt vời, bạn có thể sử dụng javafx.embed.swing.JFXPanel để nhúng phần tử JavaFX của bạn. Xem khả năng tương tác swing-fx . (Để hoàn thiện, bạn cũng có thể nhúng vào SWT.)

Swing đang trở thành một công nghệ kế thừa, hoặc đã có. Tuy nhiên, nó khá tốt trong những gì nó làm và sẽ không biến mất trong bất kỳ tương lai gần nào, vì vậy tôi thấy không có lý do gì để rời xa nó, đặc biệt nếu một người đã đầu tư vào nó. Phần mềm JIDE làm cho các thành phần Xoay (thương mại) tốt để thay thế những gì còn thiếu từ Xoay tiêu chuẩn. Ví dụ, có thể sắp xếp theo thứ tự trong lưới của họ ra khỏi hộp.

Mặc dù các phiên bản JavaFX mới trông rất ấn tượng, tôi nghi ngờ rằng nó đáng để thực hiện di chuyển hoàn toàn trừ khi bạn sẵn sàng đầu tư nhiều thời gian / công sức / tiền bạc vào việc đại tu hoàn toàn GUI.

Swing có thể có những đặc điểm riêng và đang thể hiện tuổi của nó nhưng cũng có một số lợi thế:

• Khả năng đa nền tảng rất mạnh, hiện tốt hơn nhiều so với JavaFX
• Nó trưởng thành và đã được chứng minh, nhiều hơn so với JavaFX
• Nó có một cộng đồng người dùng / hệ sinh thái thư viện lớn
• Bạn có thể đã có rất nhiều kỹ năng Xoay hoặc có thể thuê người dễ dàng với họ

Cuối cùng, nếu nó không bị hỏng, tại sao phải sửa nó?

Tất nhiên, đối với một dự án mới, tôi sẽ xem xét rất nghiêm túc về JavaFX, Android và / hoặc GUI dựa trên web (có lẽ với một cái gì đó như Vaadin).

Tôi đang ở vị trí tương tự như OP - có các ứng dụng swing kế thừa nhưng cần triển khai các thành ngữ và giao diện mới mà nó không hỗ trợ. Các ứng dụng lớn nhất trong số này đã được tái cấu trúc một vài lần vì nhiều lý do (cải thiện tính mô đun, MVC tốt hơn và cấu trúc gửi sự kiện, v.v.) vì vậy tôi không hoàn toàn phản đối việc viết lại mã UI. Vì vậy, tôi đã suy nghĩ rất lâu về vấn đề này.

Tuy nhiên, một số điều không thể được giải quyết với Swing mà không cần đầu tư nhiều thời gian và công sức hơn cho những gì thực chất là một công nghệ kế thừa. Ví dụ, ngoài các sự kiện chuột đơn giản, các thiết bị màn hình cảm ứng mới và không được chính Swing hỗ trợ. Việc cung cấp một thành phần trình duyệt dựa trên Swing cũng tương tự rắc rối hoặc tốn kém, và trong trường hợp của tôi, cách tiếp cận javafx-in-swing không phải là một lựa chọn vì nó làm phức tạp việc xử lý sự kiện UI theo những cách không tầm thường.

Tôi nghĩ rằng nó đã cũ và trung thành trong thời đại của nó, và nếu nền tảng của bạn không thay đổi như cơ sở mã của bạn - rõ ràng là gắn bó với nó. Nhưng để một ứng dụng tiến lên trong các trường hợp sử dụng mới hiện đại hơn, JavaFX 2+ có thể sẽ là cách để tiến lên trong trường hợp của tôi.

Như một lưu ý phụ: một lỗi sai trong Swing mà tôi rất thích đã biến mất trong jfx - nhưng không - là cách tiếp cận một luồng cho tất cả các quy tắc đối với việc gửi sự kiện UI. Bất kỳ giao diện người dùng không tầm thường nào cũng cần đa luồng để giữ cho giao diện người dùng sắc nét và phản hồi nhanh, và hoàn toàn phụ thuộc vào nhà phát triển ứng dụng để vấp phải những cạm bẫy tương tự rất dễ xảy ra trong IMHO API.

Tôi đã có trải nghiệm tuyệt vời khi sử dụng RCP trong các ứng dụng lớn, dựa trên máy tính để bàn. Về cơ bản, nó bắt đầu như một sự trừu tượng hóa của lớp GUI của Eclipse và đã đi một chặng đường dài kể từ đó. Thay vì Swing, dựa trên AWT, RCP xây dựng trên JFace, lần lượt dựa trên SWT. Nó cho phép bạn phát triển các ứng dụng và sử dụng các khái niệm GUI mà chính Eclipse sử dụng (các khung nhìn, các trình soạn thảo, các phối cảnh, trình hướng dẫn, v.v.). Nó rất có thể mở rộng và, giống như chính Eclipse, liên tục được cải thiện.

Tuy nhiên, tôi chưa bao giờ di chuyển một dự án hiện có từ Swing sang RCP; Tôi tưởng tượng rằng sẽ mất khá nhiều thời gian để quấn đầu quanh các mô hình khác nhau và nếu bạn không tách mô hình của mình và xem các lớp tốt, bạn chắc chắn sẽ có một khoảng thời gian khó khăn. Nhưng vì bạn đã hỏi về những thứ như bảng cây có thể sắp xếp, RCP rất tuyệt ở đó.

Nếu bạn muốn nối lại điều này hơn nữa, bạn có thể muốn thử hướng dẫn của Lars Vogel hoặc xem một số ví dụ về các dự án nguồn mở hoặc các dự án thương mại sử dụng RCP.

(Ví dụ, một bảng cây có thể sắp xếp), tôi bắt đầu cảm thấy khó khăn trong việc điền các yêu cầu. Điều này đúng đặc biệt là không có sự phát triển tích cực nào xung quanh dự án SwingX.

• không đúng sự thật, một lần nữa dự án này còn sống

• blottabla một lần khi SwingX bị mất các khoản tài trợ của Sun (trong quá trình tìm kiếm bởi Oracle), những người từ SwingX đã đến xây dựng JavaFX

Ngoài ra, tôi hầu như không thể tìm thấy bất kỳ khung công tác GUI GUI nào được duy trì / phát triển / phát triển tích cực.

• không có Swing không phải về Framework mà là về Look and Feel

• Các khung dành cho người dùng không có kỹ thuật (MsAccess có thể là ví dụ tốt nhất cho GUI Framework)

• nhưng nếu bạn muốn xây dựng một ứng dụng thực sự, bạn đã có kiến ​​thức mạnh mẽ về Swing và overriden cũng đến từ Framework,

• một ví dụ vui

Bạn đã bắt đầu di chuyển dự án Swing của mình sang khung GUI được phát triển tích cực hơn nhiều như JavaFX chưa?

không có lý do tại sao

• tương tự với việc di chuyển sang Java7, có thể khi nào sẽ có Java7.15 - 17

• Tôi so sánh JavaFx với Nimbus, quá trình phát triển đã kết thúc / từ bỏ ở đâu đó trong nửa đầu

• xin lỗi tôi không phải là nhà phát triển Tôi chỉ là Java & Swing Fan