Search code examples
javauser-interfaceswtipcrmi

Having the GUI in a separate process

I'm currently developing a GUI for a Java-application that I've created. I would like to keep the GUI in a separate process from the rest of the client. The rationale behind this is:

  • Reduced risk of crashing. E.g. a OutOfMemoryError in the GUI won't crash the rest of the client.
  • I get an API "for free". If I later on want to allow other people to programmatically access the client I can just let them use the same API that the GUI is using.
  • I'm writing the GUI in SWT and the client is created using IntelliJ. Since Eclipse has a lot better SWT-support it makes sense to keep them separate, so that I can use Eclipse for the GUI-code and IntelliJ for the rest.

My question is now: what technology should I use to expose the client's interface to the GUI? RMI is what came to mind first. However, that has the disadvantages of restricting the API to be Java only. I'm also not sure about how well suited RMI is for large scale deployment (e.g. how does it handle local firewalls?). However, I don't want to rule it out just yet.

I should also mention that I have some deployment-requirements as well:

  • Must be able to run as non-admin.
  • Must be able to handle restrictive local firewall-restrictions.
  • Deployment must be automatic (it's a large scale consumer-app) and work on Windows, Mac OS X and Linux.

Given these restriction what solution would you use?

Solution

  • I faced this same situation a while back, except that the back-end was in Python, and the GUI was in java.

    Important points to consider:

    • how flexible and granular the interface between the GUI and the back-end needs to be. Do you want to be able to do one thing from the GUI? 5 different things? 10? 50? How tightly coupled is the GUI -- will it know about/be calling individual methods in the back-end?
    • how the output gets from the back-end to the GUI. Can it simply write to STDOUT or to temp files? Does it need something more elaborate?
    • the format of the output. Ideally, it should be easily parseable, which indicates XML or JSON may be your best bet.

    You might find JSON-RPC useful: it's a standard for remote method calls to separate programs.

    All in all, it's hard for me to say what would be best for you. I ended up avoiding RPC, and gave the back-end a simple command-line interface; output was written to temp files and STDERR, as JSON objects. I feel that this was a good decision because it kept the interface between the programs very simple and uncoupled.