JasperReports is a powerful open source reporting tool that has the ability to deliver rich content onto the screen, to the printer, or into PDF, HTML, XLS, RTF, ODT, CSV, TXT and XML files. It is entirely written in Java and can be used in a variety of Java-enabled applications to generate dynamic content. Its main purpose is to help create page-oriented, ready-to-print documents in a simple and flexible manner.
JasperReports organizes data retrieved from a data source according to a report-design defined in a JRXML file. In order to fill a report with data, the report-design must be compiled first.
The compilation of the JRXML file representing the report-design is performed by the compileReport() method exposed by the JasperCompileManager class. Through compilation, the report design is loaded into a report-design object that is then serialized and stored on disk ( JasperReport class). This serialized object is used when the application wants to fill the specified report-design with data. In fact, the compilation of a report-design implies the compilation of all Java expressions defined in the JRXML file representing the report design. Various verifications are made at compilation time, to check the report-design consistency. The result is a ready-to-fill report-design that will be used to generate documents on different sets of data.
In order to fill a report-design, one can use the fillReportXXX() methods exposed by the JasperFillManager class. Those methods receive as a parameter the report-design object, or a file representing the specified report-design object, in a serialized form, and also a JDBC connection to the database from which to retrieve the data to fill the report with. The result is an object that represents a ready-to-print document ( JasperPrint class) and that can be stored on disk in a serialized form (for later use), can be delivered to the printer or to the screen, or can be exported into a PDF, HTML, XLS, RTF, ODT, CSV, TXT or XML document.
As you can see, the main classes to use when working with JasperReports are:
These classes represent a facade to the JasperReports engine. They have various static methods that simplify the access to the API functionality and can be used to compile an JRXML report design, to fill a report, to print it, or to export to other document formats (PDF, HTML, XML).
In addition to these facade classes, you will also get to work directly with specific exporter classes, in case you need to export your reports to XLS, RTF, ODT, TXT or other document formats for which there is no corresponding helper method in the JasperExportManager, or when you need to configure the export process and adapt it to your specific needs. These exporter implementations can be found in the net.sf.jasperreports.engine.export package of the JasperReports library.
If you need to display the report inside a Swing application, you can use the JRViewer component that is shipped with the library and consists of an embeddable and configurable javax.swing.JPanel component. The JasperViewer is a stand-alone Swing application that uses the JRViewer component to display reports in proprietary format (serialized JasperPrint objects) or in XML format. To help with the report design work, JasperReports provides a report design previewer in the JasperDesignViewer class.
As mentioned, a report design represents a template that will be used by the JasperReports engine to deliver dynamic content to the printer, to the screen or to the Web. Data stored in the database is organized according to the report design to obtain ready to print, page oriented documents. The report designs are defined in JRXML files and must have a special structure. This structure is declared in a DTD file supplied with the JasperReports engine. The JRXML files are then compiled, in order to use them in report filling operations.
To create a simple report design, we have to edit an XML file with the following structure:
To have a better understanding of the structure of a JRXML file, or of a report design in general, we recommend you to use the Quick Reference.
A report design is represented by a JRXML file that has the structure defined in the jasperreport.dtd file, or by an in-memory JasperDesign object. In order to generate reports according to such a report design, this needs to be compiled. Report design compilation can be done using the compileReportXXX() methods exposed by the JasperCompileManager class and results into a *.jasper file or a JasperReport object.
When compiling a report design, the engine first performs a validation to ensure that the template (JasperDesign) is consistent and then transforms all the report expressions in a ready-to-evaluate form, storing them inside the resulting compiled report template (JasperReport or .jasper file).
This transformation implies either the on-the-fly compilation of a Java class file that will be associated with the report template, or the generation of a Groovy or BeanShell script to use when evaluating report expressions during the report filling process, depending on the specified report expression language for the report (see the language property of a report template).
Before reading more about report compilation, you should understand when do you need to compile your report templates and which is the best way to do it by reading the following FAQ:
To make report design compilation process as flexible as possible, a special interface called JRCompiler was introduced.
As seen above, there are several different types of classes implementing this interface shipped with the library:
For more details about report compilation, check The Definitive Guide to JasperReports.
Ant task for compiling report designs
Since the report design compilation process is more like a design-time job than a runtime one, an Ant task was provided with the library in order to simplify development.
This Ant task is implemented by the JRAntCompileTask and is very similar to the Ant built-in task, as far as syntax and behavior are concerned.
The report design compilation task can be declared like this, in a project's build.xml file:
In the example above, the lib folder should contain the jasperreports-.jar file along with its required libraries (including the jdt-compiler-.jar, which is the recommended report compiler, in case you use Java as the report expression language).
This user-defined Ant task can be then used to compile multiple JRXML report design files in a single operation, by specifying the root directory that contains those files or by selecting them using file patterns. Attributes of the report design compilation task:
| Attribute | Description |
|---|---|
| srcdir | Location of the JRXML report design files to compile. Required unless nested elements are present. |
| destdir | Location to store the compiled report design files (the same as the source directory by default). |
| compiler | Name of the class that implements the JRCompiler interface (optional). |
| xmlvalidation | Flag to indicate if the XML validation should be performed on the source report design files (true by default). |
| tempdir | Location to store the temporary generated files (the current working directory by default). |
| keepjava | Flag to indicate if the temporary Java files generated on-the-fly should be kept and not deleted automatically (false by default). |
The report design compilation task supports nested and elements, just like the Ant built-in task.
To see this in action, check the demo/samples/antcompile sample provided with the project source files.
Viewing a report design
Report designs can be viewed using the JasperDesignViewer application.
In its main() method, it receives the name of the file which contains the report design to view.
This can be the JRXML file itself, or the compiled report design (*.jasper file).
A compiled report design can be used to generate reports by calling the fillReportXXX() methods of the JasperFillManager class. There are two flavours of the fill methods in this façade class. Some receive a java.sql.Connection object as the third parameter, and the others receive a JRDataSource object instead.
This is because most of the times reports are filled with data from a relational database to which we connect through JDBC and is very convenient to have the SQL query inside the report template itself. The JasperReports engine can use the connection passed in and execute the SQL query, thus producing a report data source for filling the report.
In cases where data is available in other forms, the fill methods receiving a data source are to be used.
Generated reports can be viewed using the JasperViewer application. In its main() method, it receives the name of the file which contains the report to view.
Generated reports can be printed using the printReport(), printPage() or printPages() static methods exposed by the JasperPrintManager class.
After having filled a report, we can also export it in PDF, HTML or XML format using the exportReportXXX() methods of the JasperExportManager class.
Parameters are object references that are passed-in to the report filling operations. They are very useful for passing to the report engine data that it can not normally find in its data source. For example, we could pass to the report engine the name of the user that has launched the report filling operation if we want it to appear on the report, or we could dynamically change the title of our report.
An important aspect is the use of report parameters in the query string of the report, in order to be able to further customize the data set retrieved from the database. Those parameters could act like dynamic filters in the query that supplies data for the report.
Declaring a parameter in a report design is very simple and it requires specifying only its name and its class:
There are two possible ways to use parameters in the query:
| Parameter Name | Description |
| REPORT_PARAMETERS_MAP | This parameter will contain a map with all user defined and built-in parameters |
| REPORT_PARAMETERS_MAP | This parameter will contain a map with all user defined and built-in parameters |
| REPORT_CONNECTION | A user supplied java.sql.Connection used for JDBC datasources |
| REPORT_DATA_SOURCE | A user supplied instance of JRDataSource representing either one of the built-in data source types or a user-defined one |
| REPORT_MAX_COUNT | An integer allowing users to limit the datasource size |
| REPORT_SCRIPTLET | A JRAbstractScriptlet containing an instance of the report scriptlet provided by the user |
| REPORT_LOCALE | A java.util.Locale instance containing the resource bundle desired locale |
| REPORT_RESOURCE_BUNDLE | The java.util.ResourceBundle containing localized messages |
| REPORT_TIME_ZONE | A java.util.TimeZone instance to use for date formatting |
| REPORT_VIRTUALIZER | The JRVirtualizer object to be used for page virtualization |
| REPORT_CLASS_LOADER | A java.lang.ClassLoader instance to be used during the report filling process to load resources such as images, fonts and subreport templates |
| IS_IGNORE_PAGINATION | If set to java.lang.Boolean.TRUE the report will be generated on one long page and page break will not occur |
JasperReports support various types of data sources using a special interface called JRDataSource.
There is a default implementation of this interface, the JRResultSetDataSource class, which wraps a java.sql.ResultSet object. It allows the use of any relational database through JDBC.
When using a JDBC data source, you could pass a java.sql.Connection object to the report filling operations and specify the query in the report definition itself (see the element in the XML file) or could create a new instance of the JRResultSetDataSource by supplying the java.sql.ResultSet object directly.
With other types of data sources, things should not be different and all you have to do is to implement the JRDataSource interface, or use one of the implemetations that are shipped with the JasperReports library to wrap in-memory collections or arrays of JavaBeans, CSV or XML files, etc.
Report fields represent the only way to map data from the data source into the report generating routines. When the data source of the report is a java.sql.ResultSet, all fields must map to corresponding columns in the java.sql.ResultSet object. That is, they must have the same name as the columns they map and a compatible type.
If we want to generate a report using data retrieved from the table Employees, which has the following structure:
| Column Name | Datatype | Length |
| EmployeeID | int | 4 |
| LastName | varchar | 20 |
| FirstName | varchar | 10 |
| HireDate | datetime | 8 |
We can define the following fields in our report design:
If we declare a field that does not have a corresponding column in the java.sql.ResultSet, an exception will be thrown at runtime. Columns present in the java.sql.ResultSet object that do not have corresponding fields in the report design do not affect the report filling operations, but they also won't be accessible.
Expressions are a powerful feature of JasperReports. They can be used for declaring report variables that perform various calculations, for data grouping on the report, to specify report text fields content or to further customize the appearance of objects on the report.
Basically, all report expressions are Java expressions that can reference report fields and report variables.
In an XML report design there are several elements that define expressions:
In order to use a report field reference in an expression, the name of the field must be put between $F < and >character sequences.
For example, if we want to display in a text field, on the report, the concatenated values of two fields, we can define an expression like this one:
$F + " " + $F
The expression can be even more complex:
$F + " " + $F + " was hired on " + (new SimpleDateFormat("MM/dd/yyyy")).format($F) + "."
To reference a variable in an expression, we must put the name of the variable between $V < and >like in the example below:
"Total quantity : " + $V + " kg."
There is an equivalent syntax for using parameters in expressions. The name of the parameter should be put between $P < and >like in the following example:
"Max Order ID is : " + $P
A Report variable is a special objects build on top of an expression. Variables can be used to simplify the report design by declaring only once an expression that is heavily used throughout the report design or to perform various calculations on the corresponding expressions.
In its expression, a variable can reference other report variables, but only if those referenced variables were previously defined in the report design. So the order in which the variables are declared in a report design is important.
As mentioned, variables can perform built-in types of calculations on their corresponding expression values like : count, sum, average, lowest, highest, variance, etc.
A variable that performs the sum of the Quantity field should be declared like this:
For variables that perform calculation we can specify the level at which they are reinitialized. The default level is Report and it means that the variable is initialized only once at the beginning of the report and that it performs the specified calculation until the end of the report is reached. But we can choose a lower level of reset for our variables in order to perform calculation at page, column or group level.
For example, if we want to calculate the total quantity on each page, we should declare our variable like this:
$F new Double(0)
Our variable will be initialized with zero at the beginning of each new page.
There are also the following built-in system variables, ready to use in expressions:
When building a report design we need to define the content and the layout of its sections. The entire structure of the report design is based on the following sections: