Communication between two separate Java desktop applications
Asked Answered
E

12

56

I'm looking to develop two separate (but related) Java desktop applications.

I want the ability for one application to trigger the other, passing in data that can then be edited and passed back, i.e. the communication will be two way. If the other application is already running I want them to just communicate, i.e. I dont want to just pass arguments over the command line, etc.

Generally speaking, what strategies/techniques should I be looking at in order to achieve this?

Erewhile answered 5/11, 2009 at 14:26 Comment(4)
Great question. Did you ever implement this?Disposed
Not yet... this was some very initial research for an upcoming project :)Erewhile
Can the people voting to reopen express their reasoning?Epiphytotic
i am in the same situation, and actually thinking, why not only CLI? what's the problem?Sorel
P
24

To show how easy it is to let two applications communicate with each other, check out this network-clipboard demo using JGroups. Just start two instances and begin dropping files into one of them. The second instance will instantly show the same files.

import java.io.Serializable;
import java.awt.*;
import java.awt.datatransfer.*;
import javax.swing.*;
import org.jgroups.*;

public class JGroupsTest {

    public static void main(String[] args) throws Exception {
        final JFrame frame = new JFrame();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setVisible(true);
        frame.setSize(500, 300);
        final DefaultListModel listModel = new DefaultListModel();
        final JList panel = new JList(listModel);
        panel.setBackground(new Color(128, 0, 40));
        panel.setForeground(new Color(240, 240, 240));
        frame.add(panel);
        System.setProperty("java.net.preferIPv4Stack", "true");
        final JChannel channel = new JChannel("udp.xml");
        channel.connect("networkclipboard");
        channel.setReceiver(new ReceiverAdapter() {
            @Override
            public void viewAccepted(View newView) {
                frame.setTitle("Network Clipboard - " + channel.getLocalAddress());
            }

            @Override
            public void receive(Message msg) {
                listModel.addElement(msg.getObject());
            }
        });

        panel.setTransferHandler(new TransferHandler() {
            @Override
            public boolean importData(JComponent comp, Transferable t) {
                DataFlavor[] transferDataFlavors = t.getTransferDataFlavors();
                for (DataFlavor flavor : transferDataFlavors) {
                    try {
                        Object data = t.getTransferData(flavor);
                        if (data instanceof Serializable) {
                            Serializable serializable = (Serializable) data;
                            Message msg = new Message();
                            msg.setObject(serializable);
                            channel.send(msg);
                        }
                    } catch (Exception e) {
                        e.printStackTrace();
                    }
                }
                return super.importData(comp, t);
            }

            @Override
            public boolean canImport(TransferSupport support) {
                return true;
            }

            @Override
            public boolean canImport(JComponent comp, DataFlavor[] transferFlavors) {
                return true;
            }

        });
    }

}
Prevenient answered 5/11, 2009 at 15:33 Comment(3)
Hi @Prevenient I wanted to know is there any specific reason why you have used throws in main method as main method is a specific method we surround it with try catch. Please elaborate.Aftercare
@Aftercare - i was just being lazy. it is allowed to use throws for the main method, doesn't make a difference. i also often declare throws Exception for unit tests, so I do not have to handle all checked exceptions individually.Prevenient
thanks for replying, I mainly use throws keyword when there is some container like in struts but while I writing main method in my application (which is a specific method not common method) I use try catch block to handle Exception in my own way. Yes using throws in main method makes a difference if any Exception occurs in main method it will be thrown to JVM and your program will stop, also JVM handles thrown Exception in its own way. throws is a concept of re-throwing Exception which is used in Common Methods (methods which are used by many classes).Aftercare
J
24

It depends how would you like to communicate those 2 programs:

  • If you need only inter-process semaphores, create a file somewhere in /tmp and lock it.

  • If you need only inter-process synchronous messaging (remote procedure call), RMI should be easiest.

  • If you need asynchronous interprocess messaging, JMS should be easiest.

  • If you need inter-process shared memory, use mapped files.

  • If you need all the above, Terracotta is the easiest way: Java programs on different JVMs on the same or even different computers see each other as if they were executed inside one JVM on one machine. Splitting one program into a few doesn't even require any code changes - it's enough to write an XML config file.

Jeffiejeffrey answered 13/10, 2010 at 17:37 Comment(0)
E
19

They could each listen on a Socket. This tutorial is good to get started.

Esbenshade answered 5/11, 2009 at 14:28 Comment(3)
Is this the usual way to do it or RMI ? Or rather, what's the difference?Showy
@Showy - Sockets are a way to stream bytes off to a network stack. RMI allows for calling methods of objects that exist in a different JVM, the data exchange is opaque to RMI though still can use sockets underneath.Painful
Ic, so sockets are the best then since its simple and fastShowy
H
10

You should also consider good ol' classic RMI.

Humpbacked answered 5/11, 2009 at 14:29 Comment(2)
Is this usually the approach when I want to have two different processes?Showy
It is the elementary way of either passing Java objects back and forth between JVMs (often as different processes). You can also share object references to act on remote objects in the other JVM. Of course the whole EJB thing and frameworks failingly try to abstract away RMI, but it is a true approach to shared multi-JVM shared objects. To be fair, it is a way to invoke remote methods, but most methods return or are passed objects anyway.Painful
P
6

Have a look at JavaGroups, it will solve your communication problem and also help you to detect if the other app is running. If the app isn't running you will have to launch a new JVM for it with java.lang.Runtime.exec()...

Ping answered 5/11, 2009 at 14:51 Comment(1)
+1 for JGroups, i love it. FYI you know that this page is 10 years old and that same code has been adopted by JBoss for years now? See jgroups.orgPrevenient
S
4

Try to communicate with SocketCommunication, even if the application are in the same machine.

Here can find more info about how to do it (Sun/Java documentation).

Seeseebeck answered 5/11, 2009 at 14:30 Comment(0)
S
4
  • The "Enterprise" way to go would be to run these apps in a Java EE server or at least in a Spring framework. It's also probably vastly overkill.

  • If a bunch of data needs to be communicated, then RMI will do it.

  • If you're not afraid to hack your own protocol, data structure and error handling, you can set up server and client sockets and communicate through those.

  • I think there's a certain crude appeal to the alternative of communicating via a file in a common directory (setting up your own protocol of who writes or erases the file when), or via a shared database. Low-tech, not extremely fast, but very simple and reliable. And it's fairly easy to monitor "communication" from the outside.

Stoeber answered 5/11, 2009 at 14:43 Comment(0)
P
2

To keep things simple why not just use plain TCP sockets?

Phaedra answered 5/11, 2009 at 14:29 Comment(4)
Plain TCP sockets don't define a protocol, serialize objects or offer any error recovery, among other things. You have to take care of everything yourself. Not that RMI is much better, of course!Stoeber
But if the data is simple it's not a big deal to handle this and you don't have to bother extra configuration of things like RMI registrys.Phaedra
@Phaedra what other low level alternatives are there? Or is tcp/ip the only way to transfer data between two programs in the same machine?Showy
@Showy - Same machine opens loads of options like shared memory, local message queues, files, domain sockets. &c &c. Putting a protocol atop a network stack (e.g. TCP or UDP) lets you expand the reach off the OS instance, easily.Painful
M
1

I second Socket communication and RMI. RMI is a little more involved but is more intuitive to a programmer. It depends on what type of information you are sending though. Pushing raw bytes over to another machine might make more sense then running the RMI server and dealing with all that jazz...

Magavern answered 5/11, 2009 at 14:38 Comment(0)
F
1

It depends what kind of communication you want to do between the 2 apps. If you use sockets or RMI for example, both applications need to be up in order for the communication to happen. If the kind of communication you want to do can be more asynchronous then you can use more of a messaging based approach.

For example, ZooKeeper allows you to implement pretty much anything you want on top of very simple yet powerful primitives. This page (http://hadoop.apache.org/zookeeper/docs/current/recipes.html) explains how to build higher level constructs with ZooKeeper.

The drawback is that you need another system. If you use JGroups for example then you don't.

Hope this helps

Felting answered 5/11, 2009 at 16:24 Comment(0)
D
0

Depending on what style of communication you're looking for (high latency, lots of data, etc.) and whether or not this system may expand past simply 2 java systems, a possibility could be a messaging system using a middleware solution such as Tibco SmartSockets.

Any more info on your setup and expectations would help.

Dismay answered 5/11, 2009 at 15:29 Comment(0)
V
0

The easiest is to use RMI without standalone rmiregistry.

Server creates a local registry:

ServerImpl extends UnicastRemoteObject implements Server

rmiRegistry = LocateRegistry.createRegistry(2020);
rmiRegistry.bind("server", aServerImpl);

Client looks it up with an rmi url (similar to corbaloc:)

String url = "rmi://localhost:2020/server";
Server server = (Server) Naming.lookup(url);

I got 1000 calls in under 500 ms in a loop over the same open connection. Yes, that is milliseconds.

Idea and sample from here: https://www.censhare.com/us/resources/blog/article/file-streaming-using-java-rmi

Verse answered 14/4, 2020 at 14:37 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.