What API to use for Java Desktop applications

Asked

Viewed 2,560 times

-1

I am looking to develop a Java Desktop project and would like to analyze what would be the best API for it. I’m in need of something like the state of the art of desktop Apis for Java. I did a search and found more references to Electron, which is an API that allows you to use a container embedded in the application so that it is not exposed in a browser. I do not know if it is the only option (only found this current, Javafx and SWT seem to be outdated), so my questions are:

  1. Which Apis for Java are currently recommended for Desktop applications?
  2. Pros and cons of these Apis
  • 1

    All desktop in general I believe is lagged nowadays. Java even worse, by not having Ipps q suitable for desktop. Until pq the future is cloud, so not investing in desktop would be backward even.

  • https://josephg.com/blog/electron-is-flash-for-the-desktop/

  • @Articuno, but we have for example Ides that are Desktop. I think we’ll still have this for a while, so I think it’s important to think about current ways to develop for Desktop.

  • I find it curious you talk about Java Desktop API and quote Javafx, SWT and Electron, but not talk about Swing which is the standard library for this.

  • @Victorstafusa, Swing is no longer supported since Java 8. What came to replace it was Javafx.

  • 2

    @Giulianabezerra Where did you get this? Swing is supported yes in Java 10 and also in 11 Early access. On the contrary, the API that Oracle is looking to throw away in Java 11 or 12 is Javafx. In fact, the other day I saw a method in Swing that was added in Java 9 or 10, I will search and pass you the link. In fact, note that neither the module java.desktop nor the package javax.swing have a @Deprecated.

  • 2

    What is no longer supported are applets since Java 9. But applet is one thing and swing is another.

  • 2
  • Swing stopped being updated since java 8, but never entered status deprecated or removed. Anyone who wants to use, api ta ai available, just can not expect improvements from the java maintainer, because this will not occur anymore.

  • @Articuno and Giuliana Bezerra - https://bugs.openjdk.java.net/browse/JDK-4842658 - Please note that here, (Java 11 EA) you find two methods addAll. But here (Java 10) you don’t find them.

  • @Victorstafuses this I agree that it has to fix even, bugs, as old as the api is, it’s inadmissible to keep it, but I meant improvements of the kind, the swing api is a little bit performance and complexity, if they were aiming to improve the api, I think there’s a lot to be improved around, the swing multithreading is already something to study, especially, I find it very bad to manipulate things using that swingworker. This in situations that it is feasible, of course.

  • @Article That I Linkei above is not exactly bug fix, but rather improvement, although this is debatable. You may well put a for (or even use a stream) to call the add in his DefaultListModel, adding items one by one, or using your own implementation of ListModel to do something more complex. What this small change gives, are methods addAll to be more convenient to use and also to perform better by decreasing the overhead generated by adding the elements one by one.

  • @Articuno However, it is true that Oracle provides few resources (financial or human) for the development of Java on the desktop and has little interest in making more available, and that is the main reason why things there go quite slowly.

  • @The fact that it has stopped being updated for me is disuse of the API. I believe they only use it in the market because they haven’t migrated to newer things yet.

  • Since it became forum, How is the situation of Java GUI? If you want can respond in chat...

Show 10 more comments

1 answer

8


The truth is that no desktop Java API has gained much momentum. Java on the desktop has always been behind competitors, always being restricted to a niche.

There aren’t many Java Apis on the desktop out there, but there are some:

  • Electron - A very rich API, but it has nothing to do with Java, but Javascript. It uses a built-in Chrome implementation underneath the scenes. The advantage is that to work with it, you use the same technologies to develop on the web: HTML, Javascript, CSS, Ajax, etc. The disadvantage is that it will climb an entire browser under the cloths, which tends to consume much more memory, processing, battery and disk space than most other solutions, since Chrome is not exactly known for trying to save these features.

  • AWT - It is the first desktop API that emerged for Java, existing since Java 1.0 more than 20 years ago, so it is supported everywhere that has Java for desktop. It has some old components, but most of them (but not all) are obsolete. Some that are not obsolete are used as a basis for Swing and Javafx, while others serve as an escape valve for things that Swing and Javafx don’t do. There are two important parts here: Components Heavyweight as java.awt.Button are obsolete (although they do not have an annotation @Deprecated in them), while basic components such as java.awt.Window are still in use today. Its components are implemented through links to native components (made available through the operating system). No one recommends using AWT components directly. In my opinion, its API is horrible and hard to use.

  • Swing - It is the standard API for developing Java desktop applications. She is said to be the replacement for AWT, but this is only a half-truth. Actually, Swing performs over the AWT. While in AWT, the components are implemented natively by the operating system, Swing uses the approach of fully deploying the components in Java, which makes them quite flexible. However, I consider that Swing has a heavy API, confusing, difficult to use correctly, hard to learn and extremely verbose, and that this was the main reason that Java was never able to popularize in Skop. Another problem is that Oracle has little interest in investing in desktop development, and for that reason, don’t expect much new with Swing.

  • Javafx - Another API added with the intention of replacing the previous one (in this case Swing), but which actually makes use of the previous one. Javafx runs over Swing, so this idea of substitution is another half-truth. I don’t have much experience with it, but in the little I used, it tends to be easier than doing the equivalent in Swing, and also tries to get a little closer to the common patterns of web development. However, it has the disadvantage of not providing all the resources that Swing gives you. Another thing to note is that Oracle wants to get rid of it so that it continues to be developed independently.

  • SWT - A Java API created by the Eclipse foundation that is not built on top of AWT. It takes an opposite approach to Swing, and seeks to develop as many features as possible natively to have the best possible performance, and for this reason is much less flexible than Swing or Javafx. I have no experience with it, but the only time I tried to move, I gave up. It has little active development.

  • Liquid Engine - A modern API for creating fast evolving graphical interfaces, developed over Opengl and LWJGL. I don’t know any more details to talk about, but it looks promising.

  • jMonkeyEngine - An API for creating 3D games in Java, developed over JOGL and Opengl, but also allows you to create 2D graphical interfaces. I know little of her.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.