不同Jar / Classloaders之间的通信

Question

I've got the following problem to solve:

There are two jar files. These jar's start independently from each other.

Now, let's say the first jar A.jar calculates or computes something and has to commit the results to B.jar .

I tried to communicate via a central Singleton (enum Singleton and a Singleton that uses a own classloader as mentioned here: Singleton class with several different classloaders ).

But it didn't seem to work for me. When i start the two jar's the hashcode of the instances are different.

Can anyone tell me what i'm doing wrong? Or other ideas how to solve my problem?

Answer 1

There are two jar files. These jar's start independently from each other.

So they're separate processes . They won't share instances of classes, variables etc. You need some form of inter-process communication to communicate between them.

That would normally mean some form of network protocol (eg TCP/UDP sockets, HTTP etc.). You could also do something really simple like reading/writing a shared file (that's not particularly nice, but it is straightforward for simple cases)

Answer 2

If you are running 2 jar files separately, then each jar file runs its own JVM instance and nothing is shared between them. They are 2 seperate process. Full-Stop.

If you wish to communicate between them then here are alternatives: It depends on what kind of data you wish to transfer.

If it is only Strings, then: if number of process = 2 and if you are sure of it, then stdin &8 stdout is the best way forward. One process can start run another Jar file by creating a Process using ProcessBuilder and then using the streams to communicate. The other process can just do System.out to transfer message. This is preferred to Socket, because you dont have to handle graceful closing of socket etc. (In case it fails and the port is not un-binded successfully, it can be a big trouble)

if number of jar files > 2 (ie number of total processes) and less than say 10 , you can probably use Sockets and communicate through Socket. This should work well, though extra effort goes in gracefully managing sockets.

if number of process is Large , then JMS should be used. It does a lot of things which you dont need to handle. Too big a task if the number of processes are less.

So in your case, process is the best way forward. If the data you wish to transfer, can even be Objects. RMI can be used given the number of processes are less. If more, use JMS again.

Edit: Now for all the above, there is a lot of dirty work involved. For a change, if you are looking at something new & exciting, I would advice akka. It is a actor based model which communicate with each other using Messages. The beauty is, the actors can be on same JVM or another (very little config) and akka takes care the rest for you. I haven't seen a more cleaner way than doing this :)