5

Yes, I was a little surprised when an interviewer mentioned that they use a Java-swing GUI for a C/C++ application. I was curious and asked him how they actually integrate these together, his answer was "through messaging". Interesting! Well, I am new to this kind of approach and am curious if companies out there really use this kind of design. If yes, then is there a big advantage to this design? It's a bit difficult for me to comprehend how this design would work well, if you have any references please share.

FYI, the product is a data-backup based application (on a Linux/Unix platform possibly). Thank you.

CV

ObscureRobot
  • 7,306
  • 2
  • 27
  • 36
Chenna V
  • 10,185
  • 11
  • 77
  • 104
  • 1
    I'd guess that the only reason they designed it this way was because they had a "C/C++ guy" and a "Java guy" to work together on it and neither wanted to develop outside of their comfort zone. Sounds like bad design to me. – hspain Oct 20 '11 at 21:54
  • Not sure if this is a StackOverflow question or [programmers.stackexchange](http://programmers.stackexchange.com). I think that this may be due to the expertise of their coders -- they may be more comfortable with Java GUI's, but are fine with C/C++ "guts". Anyway, I vote that this question be moved to [programmers.stackexchange](http://programmers.stackexchange.com) as a more appropriate site this type of question. – Hovercraft Full Of Eels Oct 20 '11 at 21:55
  • 2
    Or someone with pointy hair heard that Java is great for UI/Portability (probably in the late '90s!) and forced some Java to be used. Or it could be that the back end systems depended on a lot of native code, so it was easier to just write the whole thing as a standalone C++ app. – ObscureRobot Oct 20 '11 at 21:56
  • @Hovercraft. How do I move this question to programmers.stackexchange – Chenna V Oct 20 '11 at 21:59
  • @blueskin you can `flag` your question with request for moving.. – mKorbel Oct 20 '11 at 22:10
  • 2
    While it's certainly.. unusual, good programming style is to decouple the GUI and backend anyhow and I presume that approach guarantees this almost certainly ;) The overhead of using messaging (JNI, TCP,..) should be pretty negligible for UI code and on many large projects the backend guys don't touch the GUI code anyhow. So what's the problem? – Voo Oct 20 '11 at 22:51
  • I agree with Voo. Decoupling GUI and backend to the extent of putting them in different processes is further than most applications go, but it's hardly unusual. Right now on my PC I have TrueCrypt, SSMS and World Community Grid, all of which have separate GUI processes from the process(es) doing the actual work. I don't know exactly what IPC mechanism each uses, but SSMS certainly can using "messaging" (loopback sockets). Once you have that barrier, it is (or should be) fairly irrelevant whether they're written in the same language or not, pick the best for each job. – Steve Jessop Oct 21 '11 at 01:42
  • If you need more "juice" for running heavy load algorithms in Java you can use C++ for that specific area, it has it's pros(quicker proccessing) and cons (can't run as an applet etc.). Depends again on what your doing. EDIT: Also as mentioned below intergrating API's from different languages, again it depends on what your doing! – basickarl Oct 04 '13 at 11:57

4 Answers4

8

I see nothing wrong with it. It is very common to integrate different components through messaging. I do think its generally better to have a homogeneous environment (for example, all applications written in Java rather than Java and C++), however its often the case where you must integrate with legacy or 3rd-party components written in other languages, either for cost reasons or because there is no other choice.

Messaging is a common way to do this. I consider HTTP under the umbrella of "messaging", and nearly every language has an HTTP library - which makes it a good choice as a common messaging "language". When integrating a very heterogenous system there are dedicated tools/frameworks for not only integrating components, but also for integrating messaging systems (e.g. ESBs).

SingleShot
  • 18,821
  • 13
  • 71
  • 101
  • 3
    I agree. Why rewrite a working system if you can simply add a GUI that talks to it. This happens quite often in the financial services industry, where a legacy back-end system is given a new GUI, very often in Java, that communicates via messages to the backend. In fact, a very large percentage of internet banking solutions and even ATM's work exactly in this way. – Ewald Oct 21 '11 at 09:18
3

It is hard to tell if this is a good design without more information about the application's requirements.

Another thing to consider is that sometimes interviewers will suggest strange designs to see how candidates react. I'll typically do this when I'm hiring for a role that isn't a personal competency of mine, but where I've had experience (usually f'ing things up). My goal is to see if the candidate is any better at solving the problem than me! Bad candidates will slavishly accept my poor solution. Better candidates will immediately suggest a better solution. Best candidates will compare and contrast my weak solution with their better solution and explore when each option makes sense.

I would guess that the Java front end was selected for portability reasons. I would argue for a browser-based interface to accomplish those same goals, but maybe their UI/UX people really loved Java.

ObscureRobot
  • 7,306
  • 2
  • 27
  • 36
  • "Bad candidates will slavishly accept my poor solution." - Isn't that good? The boss gives out a design and the workers are supposed to follow without talking back, at least that's how our current education is focused. And talking against an authority is considered taboo in most jobs? I'm sorry, I'm new, I'm just asking. – crjase Oct 26 '22 at 10:43
  • 1
    I can only speak to my experience as an IC on and manager of high performance teams. If the goal is to build great software, then it is everyone's job to constantly raise the quality bar. It isn't realistic to expect management to understand every detail. Good management understands this and expects recommendations from the ICs. The only tricky part is doing so diplomatically. (It is usually unwise to call your boss an idiot, even if they are one) – ObscureRobot Oct 29 '22 at 17:38
1

There could be constraints as to why they have to call the C++ functions in the first place and then on top of that they could have had distributed client requirements. How would you develop a solution, so you build a messaging system and that interfaces with the C++ on the server side. It is a working solution at the end of the day. I would not expect that the ui has to be built in C++ because the server side is written in C++, at times you need to assemble different technologies together to achieve your solution.

r0ast3d
  • 2,639
  • 1
  • 14
  • 18
1

It is a workable / OK approach, I saw it used at a very large (Fortune 20 if there is such thing) company when I worked there as a contractor 2005-2006.

When I asked why, I was told:

  1. Need Linux GUI, java/SWING is a respectable choice. I also think that they had some Java developers who needed work.
  2. They had large, performance critical code base in C++/C.
  3. They already used messaging extensively and had libraries for that.
  4. The messaging interface, while more expensive to develop, allows the team write test programs (like replace the production GUI with a python script).

That all said, Qt and GTK/Gtkmm are very good GUI frameworks, why not to use those?

Travis Pessetto
  • 3,260
  • 4
  • 27
  • 55
Radim Cernej
  • 875
  • 1
  • 10
  • 21