Communication Between Two Java Files

Question

I have a Minecraft server that is configured to change the color of my LED light strips based on what events occur in the game, however, this server only works when ran on my computer. This is because it requires the use of an Arduino to control the LED light strips.

I was wondering if there was any way to communicate through two different jar files so that, when an event happens in Minecraft, it just tells my computer through a whole different file.

For example: I use a Minecraft server hoster like Server.pro. I detect whenever a player gets damage. When a player gets damaged I want to be able to notify my computer from the host. So like this:

onDamage() {
     Print_to_other_computer(“damaged”);
}

How could I do something like that? My problem is that I have no idea where to start in communication between these two files. Maybe a database?

Answer 1

There are plenty of options:

1. Create an API on your computer's "jar file" (webservice) and call that API from your Minecraft application. That interface can be REST, SOAP, RMI or any other modern technology. (REST is the best option)
2. Enable a queue between the two applications. ActiveMQ for example. Then you have a publisher-consumer pattern.
3. You can also use an event based framework like Axon Framework
4. You can also use a database between the applications.
5. ......

Using a REST interface between the two applications is easiest and probably the best option. The best way to do that is to specify an open api specification (YAML file) and then generate the server and client side.

https://www.baeldung.com/java-openapi-generator-server

https://blog.mimacom.com/using-the-openapi-generator-for-spring-boot/

Answer 2

The question is really very broad. And with this answer, I'll just try to focus a bit on concepts and overview. It is too hard to go in debt because there are too many options.

Files vs Processes

Files consist of bytes. They can be used to encode many different kinds of content. Bytes can encode text, music, video, logic, ...

A text file that can contain executable logic written in a programming language. In most cases, you would need to compile those text files first, to create a 'binary' or 'executable' which can then be executed by the operating system.

A program or application consists of binaries. Binaries can be executed. A running instance of a binary/executable is called a 'process'.

Binaries that perform background tasks are often called "services". Services are often scheduled to run when the operating system starts/stops.

Protocols

When a process starts, it can read and write data to a terminal. It does so using 3 different streams. A stdin, stdout, stderr. This is the most basic way for applications to communicate to a user. And it can also be used to communicate to other applications.

In a similar way, you can also use streams to communicate through other channels.

When different applications communicate to each other they need to do so in a structured way by exchanging messages. The structure needs to respect a so-called "communication protocol". Sometimes protocols depend on other protocols.

On a higher level, applications communicating with each other, often want to provide a set of commands, or want to share a set of functions. Remotely executing code is often called "RPC" (remote procedure calls). A set of those shared functions are often called an "API".

Often the provided functions can be categorized in 4 categories: create/read/update/delete actions, abbreviated as "CRUD".

Network communication

When processes are located on different computers, they need to communicate over an internal (eg an office network) or public network (eg the internet)

Most networks today use the ethernet protocol (ie RJ45 cables or wifi), and on top of that, they use IP addresses to unique identify each computer. The communication is usually done using TCP (which is a kind of negotiation where one end listens for an incoming connection on a pre-determined port, the other connects to it. Then both sides can send/receive messages). Together this is called "TCP/IP". Most modern communication protocols are based on TCP/IP (although there are other popular ones).

TCP/IP describes how devices create connections, and how they send bytes to each other but does not dictate how those bytes are organized. The content itself also needs a protocol. And historically, there have been many, some are encoded and some are text-based.

Webbrowsers use the HTTP protocol for their communication. That in itself is a protocol for communication between 2 applications. ie a webbrowser and a webserver. However, the HTTP protocol can also be a foundation for other communication protocols, such as REST.

REST is a webservice protocol for communication between different applications. And probably the most popular one today.

Realtime communication

In many cases it matters how communication is triggered, which events cause the communication to start.

eg in a protocol like REST there is a client and a server. The server never contacts the client first. It is the client who initiates the communication.

Some protocols keep an active connection between a client and a server and allow data to be pushed in both directions.

Sometimes a message requires an immediate response. By contrast, on other occasions requests are stored in a "queue" and processed at a later stage. (sync vs async communication).

Some prefer to communicate through a 3rd party which acts as that buffer, a so called "messaging bus". (see: kafka, rabbitMQ, JMS for java, ...). Those technologies are better suited for async communication, and less practical for sync communication. They are great for loosely coupling systems.

Conclusion

• Files don't communicate, processes or services do.

• The choice of a protocol is a hard one because there are many options.

• There are no one-fits-all solutions.