I've will have business logic within my core POJO definition. I don't think that's a good idea because soon, I will start trying to bring in dependency injection of other member instances to help and perform the execution.
You have really hit on the main problem with intermingling data transfer objects and business classes (also called domain models). Your "POJO" plays the role of a data transfer object. This is an important thing to realize. Once one references the other, they are coupled. So long as one holds a reference to another you cannot decouple them.
The fact is your business classes need the data in the POJO. To keep them decoupled you need to introduce an object whose sole purpose is to be coupled to these two different kinds of classes. This leads you to the various data access patterns. One of the more popular ones is the repository pattern. It knows how to load the data from file and delegates to the proper parser. It takes the resulting POJOs and maps them over to your business classes.
This keeps your POJOs devoid of references to your business classes, and your business classes remain ignorant of the POJOs. This is persistence ignorance and is a very important concept allowing your business classes to remain unchanged when you change the way data is stored and retrieved.
Each repository should implement an interface defined in the same module as your business classes. This allows business and other core service classes to retrieve data by calling methods on the repository interface, so they too can remain ignorant of the persistence mechanism.
Domain model: https://en.m.wikipedia.org/wiki/Domain_model
Data transfer object: https://en.m.wikipedia.org/wiki/Data_transfer_object
Persistence ignorance: https://deviq.com/persistence-ignorance/