Most chess engines are built as standalone applications that adhere to the UCI protocol (or the older WinBoard protocol that is no longer used). The point of this is so that the user interface can be developed independently from the engine. A big benefit of this is that it means that if you write a user interface that is capable of interacting with an engine through the UCI protocol, you can load any UCI-compliant engine into the application. Many chess applications will include Stockfish in their downloads by default, but many will also distribute just the user interface and give the user the ability to specify where the engine is installed.
In general, you would be better off accepting that the engine would be a separate application that your program will interact with. You don't need the user to start the engine themselves or deal with sending commands to the engine. You would write something in the code that would deal with managing the interaction with the engine. But ultimately, running a chess engine will be resource-intensive regardless of whether it's bundled into your application or running as a separate process. So there's not really going to be much benefit for avoiding running it as a separate process, which is the way that engines are intended to be run.
Here's an article that goes through how to interact with a UCI-compliant engine (such as Stockfish) from a Java application. Essentially, your application would start a process to run the engine, and it would use the process's standard input and output streams to send commands to the engine and receive the results. You would then need to implement the code that deals with that interaction, so it would be a good idea to familiarize yourself with the UCI protocol.
