Qt vs Java for client/server application

Ben Campbell-Wallis

This is more of a post to gauge if anyone else has encountered this.
The company I joined 6 months ago were developing a Qt based application that essentially collects data via bespoke hardware, graphs it, stores it in industry standardised files, alongside allowing users to do this as a 'project' - I'm simplifying it quite a lot.
They ultimately didn't see the project through for reasons related to the lack of proving that their chosen communication wouldn't work with customers existing cabling on their current products.

The company also have another project, which is 50% Java, 50% C, it's a 25+ year old code base and is getting very difficult to maintain, so they've given the go ahead for a re-write.

A hard requirement is that it's client/server, so that when a user starts 'recording data' which can be for a number of hours, any issue in the UI or other user interactions don't stop the recording, even if they close the client and re-open it.
Another potential requirement is that the server needs to run headless on an embedded device (most likely controlled via a sequence of commands prior to start of 'recording' with data saved locally before being connected to for an 'upload' of the session.

The current team working on it are mainly C programmers with one principle dev who's written the majority of the Java over the past number of years (who won't be with us in 2 months).
The team destined to work on it are mainly C++, with little Java experience.

My initial thoughts on high level approach would be to use either:

Qt/Widgets with standard C++ gRPC server.
Qt/QML with standard C++ gRPC server (but using Qt's gRPC for the client side).
Qt Widgets/QML with Qt remote objects.
Qt Widgets/QML with web sockets.
Or

Java/Swing (with RMI).
Java/JavaFX (with RMI).
Java/JavaFX or Swing (with gRPC).
The door is still open to any of the above for a period of time while we gather the requirements on many of the lower level components and their interactions (I've been clear that the functional requirements shouldn't dictate specific languages/frameworks where possible).

Personally I prefer working with Qt/C++, it's where I've been the past decade, though switching to Java wouldn't big a massive ramp up for me, yet maybe be a challenge for the wider team.
Has anyone else been in a similar position, and what was your experience?
Let me know your thoughts, thanks.

JonB

@Ben-Campbell-Wallis
I do not know how/whether it fits in with your requirements, but you might wish to be aware that there is a Qt Jambi project which provides a complete integration to Qt from Java/Kotlin. Some guy who posts here keeps it up to date with the latest Qt releases shortly after they come out regularly.

Ben Campbell-Wallis

Hi @JonB , thanks for the response.
I'll take a look and feedback my thoughts...

ankou29666

Hi

You need to be aware that QHttpServer doesn't fulfill the security standards (stated in HttpServer module documentation). So you probably want to avoid Qt as an HTTP server for your project. but for other part of your project (including QNetworkAccessManager as a Http client), using Qt it's fine.
see limitations and security chapter

QtJambi is a suitable option if you want to build your client using Qt with Java.
However, as QHttpServer isn't suitable (at leaset yet) for the server, and as you don't need a UI for a server, I would build the server without Qt.

Assuming of course that you talk about an HTTP server, which you didn't mention. If it's TCP server, Qt should be ok. I haven't seen any similar warning about QWebSocketServer, so should be fine also.

@Ben-Campbell-Wallis said in Qt vs Java for client/server application:

A hard requirement is that it's client/server, so that when a user starts 'recording data' which can be for a number of hours, any issue in the UI or other user interactions don't stop the recording, even if they close the client and re-open it.

I just guess that your client sends the server a request to start recording, but stop recording request isn't send. So server continues recording even when client/server connection is lost (especially if it's non-keep-alive http connection). If you want the server to stop recording, then you have to send a stop request to the server when intercepting the UI close event. Or if it's a keep alive connection, stop the recording on a connection closed event.

Ben Campbell-Wallis

Hi @ankou29666 , thanks for the reply.

The system itself will be isolated from the outside world and most likely run on VLAN, however thanks for the clarification regarding the current lack of compliance from QHttpServer.

The QtJambi does look like it'll be suitable, though I'll have to dig deeper into if we can easily reuse the widget side of one of our projects (my initial thoughts are it's tightly coupled in many places and I'd personally like to migrate it to QML).

As for the current project, theres this mix of current C and Java and I'm currently wading through the huge code base to understand how much of it's truly reusable (vs the project they shelved that has much of the widget code +other features that we need).

The recording aspect will run, usually between 1h up to 7(ish) hours - that parts not fully clear yet, but those time frames are roughly where it is.
There will be a stop request that a user can use, but we'll likely build in some limits the user can set in the event the client dies or closed incorrectly.
We will be adding a 'heart-beat / keep-alive' also so the clients know if the servers status.

If we go full C++, I'd already decided we didn't need any Qt related features in the server as there's a potential that the server side 'might' need to run on a zynq device in a 'headless' mode, though this is awaiting feedback from others in the business.

thanks for the input, they're appreciated.

Ben Campbell-Wallis

@JonB - this does look like it'll suit our needs, if we decide to re-purpose the Java into a server.
It's another approach I can add which I'd not thought of, thanks!