The classical reporting process

The older versions of JFreeReport used a simple, data centric approach for generating the report contents. The report processor iterates over a single data table and like an simple deterministic state maschine, each row of data is used as input item and the report processor generates the report content for each state change event that is encountered during the iteration. Depending on its own internal state, the report procesor selects the corresponding report band and passes that band to its layout processor.

The classical model uses the same algorithms as COBOL and RPG for the reporting. That algorithm is called 'control-break-algorithm'. The main advantage of this algorithm is its very low footprint in both memory and computation time.

In that model, each report state generates exactly one layout section (these sections are called bands, for historical reasons). The JFreeReport 0.8 implementation follows this model very strictly and uses the generated states for report processing recovery. Therefore the coarse grained division into states prevents a clean implementation of subreports. Page events need to be generated within the limitations of the state model. This means, it is not possible, to generate more than one page from within a single report state. (JasperReports avoids this trap by generating the report content first. Page events get generated after the layout processing step.)

Layouting and output generation in JFreeReport is implemented using report functions. A function is called for each generated state of the report processor. Output processors itself are state dependent implementations most of the time. Combining the statefullness of the report processors with the statefulness of the outpot processor caused great pains in the past. Over the past years, the layouter code has become the code that is propably the worst to maintain or debug.