Java vs. C++ for building a GUI which has a C++ backend.

Question

Hello,

I currently have a C++ backend that I need to connect with a GUI, and since I've never built a GUI before, I was confused on where to start.

I'm comfortable writing code in C++ and Java, so I'd prefer my GUI to be in one of those languages. Also, the GUI has to be reasonably OS independent over Windows and Linux (and hopefully, hence Macs).

Now I understand that if I use Java to do it, I'll need some wrappers to do it - but I've also heard (strictly second hand) that writing a GUI in C++ is a pain.

I don't want to rewrite too much of my backend code in Java (who does??) and I was hoping for input on:

• Does either language offer serious advantages/disadvantages compared to the other?
• How serious is the wrapping issue, and how much rewriting would come in if I used Java.
• Are there any specific resources I should look at that people think would be relevant?

Thanks and Cheers All :)

Answer 1

Have a look at Qt.

In my experience communicating between two different language runtimes is always challenging. If you have a non-trivial application to build the following often pose challenges:-

• Error Handling.
• Memory Management.
• Multithreading and Synchronization Semantics.

Apart from increasing one level of indirection due to wrappers, it requires a lot of thinking like circumstances where you need to pass data structures across GUI and backend etc.

For example:- Consider passing a Java String from GUI to backend C++. Essentially, we have to extract the characters from a Java String object and make them available to the C++ developer without leaking the memory which holds them. This is an example of a basic problem (there are other aspects too like the encoding in which the characters are to be returned).

Answer 2

I can't say much about coupling Java and C++, but I suggest you have a look at Qt. It's a C++ library for a lot of things, like file and network access, but it's most famous for GUI development. It also has a nice IDE were you can build your GUI with drag-and-drop. I would also say that Qt is as OS-agnostic as it gets for GUI libraries.

Answer 3

Writing a GUI in C++ is no more of a pain than doing it in Java.

There are numerous cross-platform GUI libraries. GTK, gtk--, FoX, WX, etc. I would not recommend Qt since it's not really C++ (uses an extended version of the language requiring a special preprocessor before compilation). Plus it costs a fortune if you don't want to give away your product.

BTW, that's not how the word "hence" is used.

Answer 4

1. Wrapping is not rewriting, it's just an adapter to make both languages meet. It is straight-forward
2. As you don't seem to be fixed on a language, I would choose a .NET Gui (With C++ CLR) you'll have a GUI that is machine independent and you can easily communicate with your existing code.

For beginners WinForms is maybe easier, but try to use WPF, it's the most modern variant for GUI development in the .NET world.

Personnally I would use C#/.NET for the GUI and use a C++ CLR wrapper DLL. But it is not the only solution.

Under Linux, the best .NET implementation is MONO. For all WinForms apps I have developped (they are not the craziest ones), they ran without change. With C++/Qt you will have to recompile for each target OS.

Answer 5

Do not use Java for creating GUIs unless platform independence is a must. The user experience will be sluggish and interoperability to C++ will be a pain.

For creating native GUI in C++, you can either use GTKmm along with a library like Boost or QT. Additionally, these libraries are available for most platforms (GNU/Linux, Windows, OS X) so your application can be recompiled anywhere.

edit: use GLADE for quickly creating GUI and fill in the signal slots with C++ code in GTKmm.

Answer 6

Qt is the winner.

Answer 7

Depending on your needs, a simple web interface might be the simplest when you have no existing frontend code. Embed a tiny web server in your application and open a browser on "http://localhost:12345" (or what port you end up using).

Answer 8

You say you already know C++ and Java, and that you never did a GUI before. That means:

• no matter if you go for a Java GUI or a C++ GUI, you will need to learn how to handle the GUI framework
• if you chose Java, you also need to learn how to interface between the two languages

So staying in C++ saves you one thing to learn. Well, it's always a good idea to learn something, but might be a bad idea to learn two new concepts at the same time. Anyway, the learning might be the smaller burden, I guess there is a lot of actual work involed, even when you use tools like SWIG.

You might want to know if writing a GUI in Java or doing it in C++ is easier. It depends on the chosen Framework. For Java, you have AWT and Swing which are part of the default Java distribution, and then there is SWT which is used by Eclipse, for example. For C++, there are many toolkits, with Qt, GTK and wxWidgets being the most popular ones, and all three support every major platform. Most of those "C++" GUI toolkits also have a Java binding or even a Java port, so you could use them with Java as well.

So far I've used Swing, Qt and a few others which don't help in your situation (The UI thingy that came with Borland C++ Builder and WinForms on .NET). Basically, the concepts are the same for all those frameworks, and I found none of them being harder or easier than the other. The only exception maybe Java, because I never got those LayoutManagers to work, even though the other toolkits have equivalents to LayoutManagers that are easy to master. But maybe thats just me.

People also will tell you that Java GUIs are always ugly and don't fit the host system. Well, most Java GUIs really are, but IMHO thats not because of Java, but because of bad programming. It takes two lines of code to let a Swing app adapt to the look and feel of the OS, and most programmers simply don't put enough effort into their Java GUIs to copy and paste those two lines... you can imagine how much they care about the rest of their GUI design.

For your current situation, I would recommend a C++ GUI, but if you know how your future plans look like, and if you know you will doing Java GUIs for the rest of your life, then it's probably ok to start that now and take the extra effort of .

And if you chose C++ for the GUI, people will tell you all kind of things to pull you in any direction. All of the three big portable frameworks have their pros and their cons, but I don't believe there is any single best or worst one among them. I'd recommend Qt simply because I already used it - but if I'd happten to have used GTK or wxWidgets instead, I'd probably suggest that.

Answer 9

You did not mention the richness of the interaction between front and back ends, which would weight the importance of the existing language in your decision.

I've worked with Qt, Swing and SWT, and typically used both C++ and Java code with all of these toolkits. The interaction between languages can add additional cost/risk. However, sometimes that cost is warranted given other benefits.

If for any reason you choose a Java front end, look at JNA and SWIG.

Answer 10

Let's all be honest here. C++ just ain't on the map when it comes to portable GUIs.

Java has a consistent, portable, widely used, thoroughly documented, mature GUI toolkit. C++ has a bunch of half-assed OSS libraries that barely work, none are truly portable, plus some expensive commercial libraries that don't work on all targets they claim to, work spotty on the remaining targets, and invert control so that you are stuck in their weird framework.

Unless you need C++ for other reasons (of which there are plenty), choose Java for the GUI. The cross-over coding is trivial for someone who knows both languages, but it can get messy to manage, so you'll want to minimize the native interface as best you can. My advice here is to make a pact with your team that you will never attempt to hold pointers (or references) across the interface. It just gets messier if you do, and no debugger can save you when the lines get tangled. Instead, use integer or string keys and pass them across the native interface.