Programming

Think about why you're wanting to do this. Is there a material benefit you'll get from splitting your codebase like so? Enough to overcome the fact that you've split your codebase into two very different languages?

When you're going between languages like this, you either need some kind of communication protocol (e.g. JRPC, TCP, or maybe something home cooked) or you need a stable ABI to allow the programs to talk to each other directly.

My point is, you probably don't want to do what you're trying to do. Unless you have a really good reason, pick one language and stick with it.

i second the comment that you need to consider why you want to do this. You generally need a pretty good reason to split your codebase into multiple languages.

As far as actually doing it, you have a ton of different options, some of which have been mentioned here. Some i can think of off the top of my head:

• create a library (dll or so file or the like)
• set up a web server and use communication protocols (either web socket or rest API or the like)
• use a 3rd party communication/messaging framework like MQ or kafka or something
• create your own method of communication. Something like reading and writing to a file on disk, or a database and acting on the information plopped in

basically every approach is going to require you to come up with some sort of API that the two work together through, though, an API in the generic sense is basically a shared contract two disconnected pieces of code use to communicate.

A socket, pipe, or shared memory region?

A network connection to localhost?

Running the backend as a child process of the frontend, and using standard io?

Does the frontend need to be written in C++, or can you write the frontend in java too (in a JFrame from the javax.swing package)?