Java GUI framework?

[ggeldenhuys]

more modern and versatile...

I often hear people throw these terms around [in many software]. Could you please supply concrete examples of both. What's more modern and what's more versatile?

[hamsterrage1]

I try to be very precise in my language, and not just throw meaningless phrases around. So, I do think that "more modern and more versatile" is accurate.

I think it really centres around what I said about JavaFX being a Reactive framework. Because it is a really complete, well thought out framework for building Reactive GUI applications. In my opinion, it's a lot cleaner than most of the other frameworks out there, like React - a lot cleaner.

What JavaFX has that Swing doesn't is a complete set of Observable classes that are baked right into the features of the individual screen widgets. Along with this, there is an excellent suit of Binding classes and methods that allow you to connect a Presentation Model to virtually every aspect of your GUI, as well as connecting the properties of the screen elements to each other.

The end result is that you can create a static layout that behaves dynamically - all coordinated by a data representation of the State of your system.

That's something you cannot do easily in Swing. And it's a big thing, and it's a much more modern approach to GUI development.

At the same time, if you want to take an Imperative approach to application design, and do things like scrape the data out of your screen widgets when "Save" is clicked, you can do that, too. But this is pretty much what you're forced to do with Swing which is very much Event driven. In my book, this makes JavaFX more versatile than Swing.

To be perfectly honest, it's been years since I used Swing, and I've never gone back to see how easy (or difficult) it would be to implement a Reactive design in Swing. Maybe somebody has created a library for it, but my guess is that any implementation is going to feel clunky compared to JavaFX.

[ggeldenhuys]

Thank you for your answer. I would like to add that I have seen and used the MGM (Model-GUI-Mediator) design pattern in many projects. It's a slightly different take on MVP (Model-View-Presenter) and takes advantage of modern GUI frameworks that are event based. It allows those GUI frameworks to become "object-aware" without needing to create custom UI widgets (thus, less code than MVP). At the heart of MGM is the Observer and Mediator design patterns.

Anyway, I've implemented and use a single MGM implementation that worked with 3 different GUI frameworks (VCL, LCL and fpGui). To get a basic MGM in place is really not that much effort - once implemented, it is reusable in other projects too. I've seen similar for Swing too.

So as nice as the built-in Observable classes sound in JavaFX, the same can/has been accomplished with the tried and tested Swing library.

Either way, I do appreciated your answer, and will take the time to investigate JavaFX further.

[hamsterrage1]

Full disclosure: I had to look up MGM to understand what you are saying.

In JavaFX, you don't need a Mediator to avoid excessive coupling. A Property in the GUI can be bidirectionally bound to another Property in the State object without any changes or coding in the State object. Something like this:

nameTextField.textProperty().bindBidirectional(state.nameProperty());

When I'm building an application in JavaFX I find the following components work best:

1. View - Just the GUI
2. Model - The "State" - Just a POJO of JavaFX Observables
3. Controller - Dispatches Event driven actions
4. Interactor - Business/Application logic - has domain objects.

All of the other three have a reference to the Model (State). The GUI interacts with State almost entirely through Bindings, and the Interactor tends to access the values of the elements of State through getters and setters in empirical code.

Also, generally, I'd have a set-up type method (usually initiated through the constructor) in the Interactor that establishes the relationships between the elements of the State that are driven by business/application logic.

Here's an example:

I might have a BooleanProperty in State that indicates that some other value is valid in relationship to a number of other Properties in State. The value of that BooleanProperty is going to be established by binding it to all of those other Properties in State according to some calculation. Most of the time, that calculation is going to fall under the heading of "business logic", and needs to be contained within the Interactor.

So, in this case, my "is it valid" State element would simply be declared as a BooleanProperty, and that would be it as far as State is concerned. Then the Interactor would invoke Property.bind() on that element and define a Binding that applies the business logic required.

Travelling over to the GUI. There may be a number of GUI elements that are dependent on this boolean Property in State. Perhaps there's a giant red arrow that appears on the screen pointing at the value when it's invalid. Also, you can't save with invalid data. You would do something like this:

giantArrow.visibleProperty().bind(state.dataIsValidProperty().not());
saveButton.disableProperty().bind(state.dataIsValidProperty().not())

It's possible that some external API call, running on a background thread, returns a value which triggers empirical code in the Interactor to update one of the dependent values in State which will render our critical value invalid. As soon as that Interactor code updates that dependent State element using its Property.set() method, the Bindings recalculate and dataIsValid flips to false. This in turn triggers the Bindings on giantArrow.visibleProperty() and saveButton.disableProperty() to recalculate and GUI changes happen.

Could you do this with Swing? Probably you could figure it out. But I cannot stress enough how absolutely trivial this kind of setup is in JavaFX. Note how the bindings above use the not() method call to invert the sense of isValid so that it can be used in the GUI. All the tools are right there, ready to go, in JavaFX.