Question

I need to make a desktop app which is pretty complex and handles a particular
domain. The domain has entities at the back end. I want the UI of this desktop app to be portable
to different frameworks such as Java(Eclipse RCP Plugin) and .NET(Visual Studio Plugin). So

1.)can I write the domain layer using C++ and interface with Java using JNI for Java
2.)use same C++ layer as point 1.) for interfacing with .NET (C++/CLI) as plugin for VStudio

What are the architectural considerations, pitfalls, future issues one will face if one
relies on a portable C++ layer interfaced with higher level APIs like Java and C# for a rich
client desktop application

For example one of the issue I will face is that I cannot debug and step into Native code from Java.
Are there many such items?

Should I just rewrite my domain layer using .NET and Java for each type of environment rather than keeping it portable as C++ layer?

Why isn’t such an approach adopted by the industry?
What are the practical issues one faces when one has a JNI layer in between the View and Domain Layer?

Answer 1

Interfacing with domain models in another language / on another platform is really painful and my main architectural advice would be to avoid going there.

If you want a portable desktop app, I think you are better off writing it end-to-end in Java (or perhaps another JVM language like Scala or Clojure if you are one of the people who thinks that Java itself is a bit old-fashioned).

Rationale:

• You’ll only need to write the GUI layer once as Java will give you access to all the environments you need. You can run Java desktop apps pretty much everywhere that has a JVM, without recompiling. You just need to take a little care to avoid hard-coding platform specific features (e.g obvious stuff like don’t assume “\” as a file separator, you need to use the portable File/pathSeparator instead).
• This avoids the complexities of having to do a lot of cross-language interfacing. This is inherently a hard problem, since the languages have different object format and method calling semantics.
• Java has a great open source library ecosystem with respect to portable code.
• You can make pretty decent portable UIs in Java for most purposes (using Swing or SWT), and this is probably better in the long run than developing a custom UI layer for each target platform.
• If you are smart, you can architect the app so that the GUI interacts with the back end domain objects through a clean and simple API. If you do this, then it will be easier to add new GUI options in the future (for example a web-based front end).

Writing the app end-to-end in .Net is also clearly feasible and might even be a bit easier on the GUI side given how good Microsoft’s GUI-building tools are, but has the big disadvantage that you’re now effectively locked into Windows, so your portability and platform flexibility goes out of the window. In addition (though this will depend on your domain) I think the Java ecosystem has the overall edge in terms of library ecosystem and tool support (with things like Maven).