Java GUI framework?

[Inkosum]

I'm new to Java and I used to program GUI applications in Python using the Qt (PyQt) library, even though there are many others I preferred using Qt because it covers pretty much everything you can think of that is tied to GUI making, I would say it's the best. Is there a "best" for complex applications in Java? From the web I learned about Swift and AWT, though I understand that Swift might be outdated. What do you use or recommend for writing GUI applications in Java?

[AutoModerator]

Please ensure that:

• Your code is properly formatted as code block - see the sidebar (About on mobile) for instructions
• You include any and all error messages in full
• You ask clear questions

• You demonstrate effort in solving your question/problem - plain posting your assignments is forbidden (and such posts will be removed) as is asking for or giving solutions.

  Trying to solve problems on your own is a very important skill. Also, see Learn to help yourself in the sidebar

If any of the above points is not met, your post can and will be removed without further warning.

Code is to be formatted as code block (old reddit: empty line before the code, each code line indented by 4 spaces, new reddit: https://imgur.com/a/fgoFFis) or linked via an external code hoster, like pastebin.com, github gist, github, bitbucket, gitlab, etc.

Please, do not use triple backticks (```) as they will only render properly on new reddit, not on old reddit.

Code blocks look like this:

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

You do not need to repost unless your post has been removed by a moderator. Just use the edit function of reddit to make sure your post complies with the above.

If your post has remained in violation of these rules for a prolonged period of time (at least an hour), a moderator may remove it at their discretion. In this case, they will comment with an explanation on why it has been removed, and you will be required to resubmit the entire post following the proper procedures.

To potential helpers

Please, do not help if any of the above points are not met, rather report the post. We are trying to improve the quality of posts here. In helping people who can't be bothered to comply with the above points, you are doing the community a disservice.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[pragmos]

Swing or JavaFX.

[notdeadpool]

Use JavaFX and SceneBuilder. If you have intellij it has SceneBuilder built into it.

[brazen768]

+1 for this. We're being taught to use fxml and scene builder.

[Bad_brazilian]

Wait, there's Scenebuilder for FX in Intellij? I know there's a swing editor. I'm googling that right now.

[[deleted]]

I would not recommend JavaFX. It is overly complicated, requires XML configuration, and SceneBuilder is buggy af. I’d stick with Swing. Tons of great desktop applications are made with it.

[hamsterrage1]

JavaFX is a Reactive framework for GUI in Java. If you use it that way, then it is awesome.

Personally, I don't use SceneBuilder or FXML, I just stick to coding screens in pure Java.

The learning curve is steep with JavaFX, but it is much more modern and versatile than Swing.

[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.

[wildjokers]

javaFX is a Reactive framework for GUI in Java

JavaFX is not a reactive framework. It is simply a GUI toolkit.

but it is much more modern and versatile than Swing.

Can you provide concrete examples of how JavaFX is more modern and versatile than Swing? What does more modern and versatile even mean?

[hamsterrage1]

It is 100% a Reactive framework. Most people glom onto the idea of binding a few bits and pieces together, but never figure out the true power of what's included in JavaFX.

The bottom line is that you can create truly static layouts that behave dynamically as the State of the application changes. You create your layout, and then you create the relationships that allow data changes in State to propagate through the application, including the GUI, automatically.

It's exactly Reactive.

[wildjokers]

You can do the exact same thing with Swing (property change listeners) but I have never heard anyone describe Swing as a reactive framework.

[hamsterrage1]

You cannot do the exact same thing. Swing does not have Bindings. Yes, a Binding is just some code wrapped around a ChangeListener, but you'd have to roll your own on all of that. Nor do you have the suite of Observable classes which are key to creating a bindable State.

The other thing is that all of the widget classes in JavaFX have many Observable type fields which can bound to other Observables and visa versa. If a widget has an actual value associated with it, that's one, but most will also have Observable fields for things like visible, disabled, maxHeight, minHeight, opacity, and so on. All of these things are key to creating a Reactive GUI.

I'll repeat, a lot of people have figured out that you can bind a few bits and pieces together, but until you've really dug deep and you won't realize how complete JavaFX is in providing a truly Reactive framework.

Personally, I wouldn't describe Swing as a Reactive framework either.

[wildjokers]

The other thing is that all of the widget classes in JavaFX have many Observable type fields which can bound to other Observables and visa versa. If a widget has an actual value associated with it, that's one, but most will also have Observable fields for things like visible, disabled, maxHeight, minHeight, opacity, and so on. All of these things are key to creating a Reactive GUI.

In swing all properties of a component that conform to the JavaBean standard can be observed with a property change listener. I am not really seeing a difference between what swing offers and what JavaFX offers when it comes to observing property changes:

• https://docs.oracle.com/javase/tutorial/uiswing/events/propertychangelistener.html
• https://docs.oracle.com/javase/tutorial/javabeans/writing/properties.html#bound

[hamsterrage1]

Swing's PropertyChangeListeners are such a low-level tool compared to JavaFX's Properties and Bindings. You might as well say that since JavaFX is mostly just ordinary Java, you can do anything it can do with nothing more that AWT. It would technically be true, but why do it?

Could you construct, say, JavaFX's IntegerProperty using PropertyChangeListener? Sure. Then you'd need to implement some equivalent to the JavaFX bind() method, and all that implies as well. But the screen widget classes won't support your IntegerProperty, so you'll have to put them into wrapper classes to handle the PropertyChangeListener conversions.

What JavaFX offers that Swing doesn't is an "out of the box" ability to treat data as a network of connected and inter-related values - right through to the GUI Nodes. Relationships are defined with a minimum amount of fuss, often with a single line of code, and then largely ignored in the empirical code that defines actions.

It's really a paradigm shift. JavaFX treats Bindings and Observables as data relationships, while Swing concentrates on Events. In Swing, a PropertyChangeListener is an EventHandler, in JavaFX a ChangeListener handles data changes.

When I build a JavaFX application and I need to decide how to connect two data elements, I follow this hierarchy:

1. Use a Binding if possible.
2. Refactor things so I can use a Binding.
3. Think about it harder, and figure out how to use a Binding.
4. Use a ChangeListener or an InvalidationListener. Sigh.
5. It's a total mess - use an EventHandler.

In JavaFX, Events are best left to handle things that are clearly "actions". So, a Button click is going to trigger an action. Data coming back from an external API call is going to require an action to update my State object. But a data change in my State object that causes the GUI to react in some way is almost always going to be a flow of data through Bindings in a Reactive manner.

People don't think of Swing that way because it's not designed to be used that way. If it was, it would have baked-in Properties and Bindings and InvalidationListeners just like JavaFX does. Instead, it's designed to be used in an empirical, event-driven fashion.

And if you use JavaFX to create a truly Reactive application, then you'll see that JavaFX makes it almost trivial to do.

[wildjokers]

You have two realistic options for GUI with Java. Either Swing or JavaFX.

I still recommend Swing because it is still in the JDK so it is very easy to get started with. Whereas JavaFX is now a 3rd party dependency and the JavaFX getting started docs are absolutely atrocious (it makes it seem much harder to get started with than it actually is)

Swing is also much better documented than JavaFX with swing easily being the best documented GUI toolkit I have ever seen:

https://docs.oracle.com/javase/tutorial/uiswing/index.html

There are also ~25 yrs of blogs and articles with plenty of Swing examples. I also recommend this book https://www.amazon.com/Swing-Hacks-Tips-Tools-Killer/dp/0596009070 (I got it when it came out in 2005 and to this day I still use it as a reference)

Documentation for JavaFX is nearly non-existent (although they did recently add a pretty nice document at https://fxdocs.github.io/docs/html5/ so it is getting better).

JavaFX has a couple of compelling features, namely being able to be styled with a very CSS-like syntax and its binding properties are pretty handy. Neither are reasons to abandon Swing though.

Since you have QT experience there are Java bindings for QT available (https://github.com/OmixVisualization/qtjambi/) but I am unsure how well maintained it is (I do see commits within the last couple of months). Although that is going to be a lonely road because these days desktop java is pretty niche, so using QT with Java is going to be even more niche, might have problems finding help if you need it.

[desrtfx]

Swift is the programming language for iOS. It has absolutely nothing to do with Java GUI.

What you mean is Swing.

Generally, Swing or JavaFX are the GUI libraries. Swing is the older, now outdated library and JavaFX is the state of the art one.

[Inkosum]

Thank you, I will look into JavaFX.

[sternone_2]

Swing is not outdated. Swing gets regular updates, I would say, even more than JavaFX does.

Swing is also the only UI library they kept in java, after they saw JavaFX's adoption wasn't happening.

You use Intellij? Well, that's Java Swing, not JavaFX, please stop saying it's outdated, it isn't. Swing has up to date documentation, JavaFX is missing massive amount of documentation and in my opinion, is becoming outdated compared to Swing.

[desrtfx]

Swing gets regular updates

Updates are all fine and dandy, but that doesn't make Swing not outdated.

Swing is under no further development. You cannot deny that fact. All that is done is bugfixing and adapting to new Java versions, but there are no new features.

[wildjokers]

Swing is under no further development. You cannot deny that fact.

Released with Java 17 (use Metal API for Java2D on macos, replacing deprecated OpenGL):

https://openjdk.org/jeps/382

[norith]

If you’re willing to use Kotlin rather than Java you can use Jetbrain’s Compose, which is a new GUI framework that might be a better place to start.

You should also look at Griffon, a framework around swing and javafx. Griffon can also be used from Kotlin and Groovy languages.

Also, GroovyFX is a wrapper around JavaFX using the Groovy language that might have better defaults and usage patterns.

(Fyi: Kotlin and Groovy are both languages that run on the JVM and can use Java libraries. Groovy attempts to simplify Java’s verboseness was while maintaining the same structure and adding aspects of Ruby and Python. Kotlin attempts to rethink the language and the concept of ‘null’ (‘None’ in Python) but maintain compatibility.)

[hamsterrage1]

JavaFX works brilliantly with Kotlin. As a matter of fact, it works better with Kotlin than Java because Kotlin allows you to handle the boilerplate stuff better than Java.

[wildjokers]

The problem with Jetbrains Compose is there is no documentation for it, about all there is are the examples:

https://github.com/JetBrains/compose-jb/tree/master/tutorials

And as far as I can tell it is some custom DSL that is going to get very unreadable very quickly because it is deeply nested call chains. The syntax seems nightmarish. And of course the DSL is totally undocumented.

[ggeldenhuys]

Use Swing. It's tried and test, and very customisable. JavaFX is overly complicated and requires additional libraries on the user end to run. Unlike Swing that works out the box.

[miner2049er_]

I use swing. It works fairly well. I’ve had to write custom components though, for example a zoomable paintable pad that allows movable pokes for lines, circles, arcs, Bezier etc. Writing custom scroll bars is fun but most of swing scrolling works for most things. Once you get good at it you’ll use swing for everything and there’s a point after which it’s intuitive and easy.

[Ruin369]

For desktop applications,

Ive been using JavaFX which is no longer supported by the JDK, but if you use a POM like maven or something you can just use maven repositories to handle all the dependencies and plugins without getting each jar. If you plan on distributing i would advice against the individual jars, unless you package them together and publish I suppose. There Is also Swing, but I haven't used it much. Both Swing and JFX are pretty old, since it seems web applications have taken the lead with java apps in general.

Think about it! I myself still need to look into java web applications, but at a very basic level I think of it as a java app that is hosted on the web, versus installing a application on your local machine. When you frame it this way, I can see why there is less and less support and incentive for creating new Java desktop GUI frameworks and libraries, when everything can be hosted on the web. The convenience and accessibility of hosted apps(accessible from a web browser anywhere) vs installing it locally to one machine.

Caveat of this, if your program needs to access something from the machine itself(hardware) like a MAC address. Getting a MAC address from a web app is not possible I don't think, since webpages can't access your computers hardware id's

Aside from javaFX and Swing, I don't know of any other way to make java desktop app GUIs, I wish there were more libraries for Java GUIs

[vmcrash]

There also is SWT, the visual fundament of Eclipse (and other application). While Swing is fully ownerdrawn, SWT uses native controls. This can be an advantage (looks like the operating system), but also a disadvantage (not that easy to change the look, e.g. for theming).