Is resorting to cyclic dependency bad if its being used to maintain readability of legacy Java application?

So i started working on this legacy java/spring application (its literally half spring since it was coded with Java initially and so not fully spring) and theres this reportservice class. Essentially a bunch of report classes of different types will call a general generation method in reportservice which basically checks which report type it is and then sets some properties for a report job which is done via oracle reports or an external server.

Details are not that important but basically I am changing or optimizing the generation service to be generate within the app and not using an external server. However this means that i no longer need to set properties for the job, so initially i wanted to add the generation methods inside of the report type class and call them from within instead of needing to continue calling the generic method in reportservice since im not using a job anymore.

However a senior dev said that for the purpose of readability like so that the next developers who work on it can understand the flow and to remain consistent and i guess until ALL reports are changed we should keep using the general method in reportservice, however this means cyclic dependency because essentially i am calling the generate method in reportservice from a certain report type class and then that is going to call the new generation methods inside the same caller report type class, which i thought is quite redundant and bad practice. Something that i an do to avoid this cyclic dependency is to move the actual generation of type report in to reportservice but thats also bad practice since then i'd have to add the other type of reports generation methods in there as well, or i could create another util class for that report type that has the generation methods but then again i'd have to do that for every report type and it doesnt seem like the best idea.