JenerateIT provides a plug-in mechanism to add generation logic to be controlled by JenerateIT. We, amongst others, have developed generation logic that knows how to generate a Java file. That generation logic uses JenerateIT’s plug-in mechanism and JenerateIT’s API.

JenerateIT, through its API, provides the means to split a to-be-generated file into different sections. With this, generation logic at any time can write to any section of the to-be-generated file. The generation logic actually is writing to specific buffers and not to the physical file. The physical file then is written only at the end of the code generation process.
The aforementioned generation logic for the creation of Java files utilizes that means, for instance to generate import statements in an efficient way.

Does this throw light on my original comment and answer your question?

By the way: in a few places in generation logic we use StringTemplate to generate chunks of pure text that have only little or no variability.

When you said: “Instead, when generating a Java file, you for instance can add import statements while generation logic is just writing the implementation of a method.”

Then, if I understood it well, the template engine is taking in account that you are generating Java code and already knows what an “import” means in this context? We can say that your code generator is specially targeted for Java output, isn’t it?

Let me try to outline how that object-oriented generation framework „JenerateIT“ performs in relation to the 7 requirements you have listed further above. Please note that if there were a „JenerateIT for Visual Studio“, you would have a similar situation for the C#/C++/.NET world. In order to avoid misunderstandings: JenerateIT does not do simple System.out.println() calls, but acts on a higher level. Amongst others this approach frees you from having to write to a file sequentially. Instead, when generating a Java file, you for instance can add import statements while generation logic is just writing the implementation of a method.

Direct recognition of the final output
=========================================
Since object-oriented code is not procedural, the code that contributes to the generation of a file cannot be seen at a glance. That’s the price you have to pay in order to get all the advantages mentioned in the remainder of my post.
To improve the readability and comprehensibility of generation logic, JenerateIT comes with traceability functionality to directly show the relation between generated code and generation logic that created it. Also, you can directly jump from generated code to the generation logic code.

Easy to maintain
=========================================
Changing a template in JenerateIT (= a set of classes that implement generation logic) is equivalent to changing object-oriented Java code. So you may imagine how easy that is. Surely, you have to be familiar with Java and with object-orientation.
Additional functionality that eases maintenance tasks is mentioned in the last part of my comment on „Direct recognition of the final output“ further above.

Reusable
=========================================
From anywhere in the generation logic you have full access to all other available generation logic. And that can easily be re-used.

Minimalistic
=========================================
When you generate Java code with JenerateIT, your target language is the same as the language for programing generation logic.

Composable
=========================================
Here the same comments hold true as were given for the „Reusable“ requirement further.

Separation of Concerns
=========================================
JenerateIT doesn’t care about the content that your generation logic is going to write into the generated files. It is responsible only for controlling your generation logic, handling model access and file input and output.

Idempotent
=========================================
With JenerateIT you can re-generate a file as often as you want. The content is not changed, and also, if the content doesn’t change, the physical file is not being overwritten. So it keeps the original timestamp. There is an exception from that rule: if your generation logic generates timestamp information or random data into a file, obviously that file will change with every re-generation.