0

I am developing a JavaFX application (Gradle, Intellij) that performs some operations remotely by connecting to an application server via WebSocket. The server is developed using Spring Boot and implemented as a STOMP WebSocket. The client part shall be somehow integrated into the existing JavaFX application. The integration of JavaFX and Spring Boot has good documentation. This post on Stackoverflow is not too recent, but there is this post on Spring blog, but also some other material based on the same idea like: samydavic blog, this project on GitHub and this post from the same person. The solution presented is very elegant but actually changes the JavaFX application to a Spring Boot application and looks too complex for the kind of application I am developing, which basically sends a json object to the server and receives another one as response. There are some useful tools like FxWeaver, spring-boot-starter-javafx but again, the are additional dependencies and more stuff to handle.

My question is: what alternative solution can be recommended (if any) to let my existing JavaFX application to have a simple stomp websocket client added?

An option which I am considering is to have a Spring Boot websocket client and to have it connected to the JavaFX application via a socket over TCP (since they will both run on the same machine) which is very easy to implement; the websocket client would work as a message broker for JavaFx application.

CT95
  • 107
  • 1
  • 11

1 Answers1

2

This is subjective, so it is an opinion, there is not really a right or wrong answer.

You don't need 3rd party things like fxweaver, spring-boot-starter-javafx if you don't want them. You can integrate JavaFX and spring boot directly. Once that is done you can use the appropriate starter projects from spring boot as dependencies to add the functionality you need.

If you just want to use raw web sockets, you don't need spring at all, as the functionality for websocket clients is in the JDK.

Working with native web sockets seems simple but can be trickier than you expect because it is a low-level system without a defined protocol for messaging. If you do want to use stomp over websockets instead, it may not be overly complex, though there is a learning curve either way.

jewelsea
  • 150,031
  • 14
  • 366
  • 406
  • Indeed this is a subjective answer and quite open, but good to know ideas from the community. Thanks for pointing to [how to integrate JavaFX and Spring](https://stackoverflow.com/questions/57887944/adding-spring-dependency-injection-in-javafx-jpa-repo-service/57896435#57896435), gives a very good hint. Interesting is the concept of "separation of concerns" which in my case makes lot of sense because I will probably not make a massive use of Spring and the idea of have it somehow separate from the GUI is interesting. Also [Gluon Ignite](https://gluonhq.com/labs/ignite/) is worth considering – CT95 Feb 24 '23 at 17:05
  • I can't help but feel that any attempt to merge JavaFX with Spring or Websockets is wrong-headed. Your API/Websocket stuff should be implemented in as a Service that's called from your JavaFX business logic - which should be the Model (or some equivalent). The Model deals with integrating the Domain Object data to/from the Presentation Data. Take a look at this article I wrote: https://www.pragmaticcoding.ca/javafx/weather – DaveB Feb 24 '23 at 18:52
  • Thanks DaveB, the article and the sample code are very interesting. I share your view and would prefer to have JavaFX decoupled from the service. What I am interested is to have the simplest solution, if I can achieve that integrating JavaFX with Spring, I would go with that. Gluon Ignite looks promising – CT95 Feb 24 '23 at 19:48
  • Testing Gluon Ignite, maybe somebody can help with this [problem](https://stackoverflow.com/questions/75561231/javafx-app-integrated-with-spring-boot-and-gluon-ignite-does-not-load-fx-runtime) – CT95 Feb 24 '23 at 20:48