How can two programs talk to each other in Java?

Question

I want to reduce CPU usage / ROM usage / RAM usage - usually all the system resources that my application uses - who doesn't? :)

For this reason, I want to split the settings window from the rest of the application, and let the settings window run as an independent program.

The settings program should write to the Property file (not a problem at all) and send an “update signal” to the main program - this means that it should call the update method (which I wrote) found in the main class.

How can I call the update method in the main program from the settings program?

In other words, is this a way to create a settings window in which when the window loads, just ?

Is this approach to separate programs and letting them talk to each other (somehow) is the right approach to speed up my programs?

Answer 1

What you are describing looks like Premature Optimization . If you are writing something other than a toy application, it is important to be sure that your optimizations really solve the real problem. Is your program running slowly? If so, do you run it through the profiler or otherwise identify where low performance occurs?

If you have determined that what you want to do will concern your performance problem, I suggest you take a look at launching components simultaneously in different threads, not different processes. Then your components can avoid blocking each other, you can take advantage of multi-core processors, and you will not take on the complexity and performance of the overhead of interprocess communications through network sockets, etc.

Answer 2

You can talk back and forth using sockets. Here is a tutorial on how to do something like this. .

Unfortunately, I do not think that this will help you minimize the use of CPU, RAM, etc. If anything can increase CPU usage, RAM usage, etc., because you need to run two JVMs instead of one. Unless you have a window with incredibly complex settings, it is unlikely that you will need many resources that you need to worry about. By adding network connectivity, you simply add more complexity without adding any benefits.

Edit:

If you read Filthy Rich Clients, one of the highlights of the book is that Rich Effects doesn't have to be resource intensive. The main part of the book is devoted to how to add cool effects to the application without taking up a lot of resources. Throughout the book, they are very careful to show everything that takes a lot of time and what does not. This is critical when you make an application less resource intensive. Write your application, see what it feels slow, add a time code to those details that are slow, and speed up these specific parts of the code. Check your time code to see if it is really faster. Rinse and repeat. Otherwise, you are doing an optimization that may not make any difference. Without considering the time of your code, you don’t know whether you need to speed up the code, even if you have accelerated it after optimization.

Others mentioned loading the properties window in a separate thread. It is important to remember that Swing has only one thread, called EDT , which performs the entire picture of the pixels on the screen. Any code that causes a change in pixels on the screen should be called from the EDT and, therefore, should not be called from a separate thread. So, if you have something that can take some time (maybe a web service call or expensive calculations), you should start a separate thread with EDT, and when it finishes the startup code in EDT to update the user interface, there are libraries such as SwingWorker to make it easier. If you set the dialog to be visible, it should not be in a separate stream, but it makes sense to create data structures in a separate stream if it takes a lot of time to create these data structures.

Using Swing Worker is one of the many valuable ideas at Filthy Rich Clients to make the interface more responsive. Using the ideas in this book, I used a rather resource-intensive interface and made them so that the user interface practically did not use any resources.

Answer 3

You can create a ServerSocket in the main window and connect the settings application to it using the usual Socket protocol used can be very simple, but ... I think you should really look for a second approach: to create a settings window that accept system resources only when do they appear?

To do this, you need to create a window and all its resources until the user performs the "Settings" action, saves your file (or transfers the contents to the main application) and deletes all the resources of the preference window, making all its links inaccessible. The garbage collector will handle the rest.

Answer 4

Perhaps you could use some kind of observer from the directory, like this, or maybe implement some kind of semaphore. Honestly, I think you should solve this problem if you have any menu item that the user can access. After that, the user saves the settings, they are written to a file. The application then loads the values ​​from the file every time it is needed. If your system is slow or hanging, you can consider using threads or increase the number of threads.

Answer 5

Actually, as others have explained, you can use a socket for interprocess communication. However, this will not reduce the overall CPU / RAM usage. (may even slightly degrade resource use)

In your case, you can launch the Perference window in a different topic, and not in another Process. The thread is easier for the OS to process and does not create additional complexity for interprocess communications.

Answer 6

No one seems to have mentioned DBUS - available to developers on a Linux system. I suppose it's not good if you are trying to create a Windows / Cross Platform application, but DBUS is a ready-made platform for applications and communications. It helps to resolve issues such as:

• Someone else can use the port you are trying. There is no way for your client application (I think this is the Preferences window) to find out if listening to this port is your main application, or just something else that happens there, so you will need to do something like a handshake and implement a conflict resolution mechanism.
• This will not be obvious to the future, nor to those who come to support your application, why you are at this port. This may not seem like much, but chatting on Socket 5574 just doesn't seem as neat to me as chatting on org.yourorganisation.someapp.
• Firewalls (as I think someone already said) can be a bit more zealous

It’s also worth a hand on DBUS - it is useful for communicating with a number of other applications, such as a little information about tooltips that you will find in the latest Ubuntu distributions or some instant messaging clients, etc.

---

You can read about what I'm talking about (and maybe correct me for some of the things I said) here: http://www.freedesktop.org/wiki/Software/dbus . They seem to be working to make this happen on Windows as well, which is nice.