How to Install and Configure Jasper Reports in Eclipse

how to generate jasper reports in java using netbeans and how to call jasper report from java class and how to run jasper report from command line
OliviaCutts Profile Pic
Published Date:01-08-2017
Your Website URL(Optional)
THE JASPERREPORTS ULTIMATE GUIDE PAGE I GETTING STARTED This chapter is for those who have never used JasperReports. If you have already installed JasperReports and used the samples, you can skip the chapter. INSTALLING JASPERREPORTS JasperReports is a content-rendering library, not a standalone application. It cannot run on its own and must be embedded in another client- or server-side Java application. JasperReports is a pure Java library and can be used on any platform that supports Java. Being a library, JasperReports is completely agnostic about the environment in which it is used for generating reports. All JasperReports functionality is concentrated in a single JAR file, jasperreports- x.x.x.jar, available for download at the following URL: group_id=36382&package_id=28579 Even though all its reporting functionality is available in this single JAR file, JasperReports relies on other third-party libraries for related required functionality like XML parsing, logging, and PDF and XLS generation. Because JasperReports is a library and cannot run on its own, you do not really install it. “Installing” JasperReports simply means downloading its JAR file and putting it into the classpath of your application along with the other required JAR files. REQUIREMENTS JasperReports handles only reporting. It relies on third-party libraries and APIs to perform needed functionality like XML parsing, database connectivity, PDF or XLS output, and so on. This section contains all the libraries that JasperReports may require, depending on the functionality required by JasperReports’ parent application. The two types of requirements for using JasperReports are the following:  Absolute requirements, needed regardless of the module of JasperReports that is actually used.  Optional requirements, needed only for a specific JasperReports function. (If a PAGE 1THE JASPERREPORTS ULTIMATE GUIDE certain function of JasperReports is not used by the parent application, then the required libraries needed by that module can be skipped at deployment time.) The following list details the requirements for using JasperReports:  Java Virtual Machine (JVM), JRE 1.3 or higher  One of the following for report compilation, depending on the report compiler used: Eclipse JDT Java compiler ( JDK 1.3 or higher Jikes ( Groovy ( JavaScript ( BeanShell (  JAXP 1.1 XML Parser  Jakarta Commons Javaflow, sandbox version (  Jakarta Commons Digester component, version 1.7 or later (  Jakarta Commons BeanUtils component, version 1.4 or later (  Jakarta Commons Collections component, version 2.1 or later (  Jakarta Commons Logging component, version 1.0 or later (  JDBC 2.0 driver  iText (free Java PDF library by Bruno Lowagie and Paulo Soares), version 1.01 or later (  The following APIs for XLS: Jakarta POI, version 2.0 or later ( JExcelApi, version 2.6 or later (  JFreeChart (free Java chart library), version 1.0.0 or later ( PAGE 2THE JASPERREPORTS ULTIMATE GUIDE X11/HEADLESS JAVA JasperReports relies on AWT rendering when generating reports, so it might not work if you are using it in a server environment running UNIX/Linux without graphics support. The application might raise errors such as “Can’t connect to X11 window server using ‘:0.0’.” To solve this problem for JVM releases prior to 1.4, provide a pseudo–X server to emulate a display environment. Following are some of these emulators:  X Virtual Frame Buffer (Xvfb)  Pure Java AWT (PJA)  Virtual Network Computing (VNC) The preferred solution for JRE 1.4 or higher is to use the new headless AWT toolkit. This new feature allows you to use the J2SE API in a server-side Java application without a GUI environment. To specify the headless environment when using the Sun Microsystems reference implementation, run your application with this property: -Djava.awt.headless=true BUILDING THE SOURCE FILES AND RUNNING THE SAMPLES The best way to start working with JasperReports is to download the full project package from the following location: group_id=36382&package_id=28579 The file available at this location contains all the source files, required libraries, and freely available documentation, as well as a complete set of sample applications and reports. Download the archive and extract its contents to the directory of your choice on your local machine. You’ll be able to see JasperReports in action without having to create a Java application to embed JasperReports in. ANT BUILD TOOL Before using the JasperReports distribution files and samples, install the Ant tool on your machine. JasperReports relies heavily on the Ant build tool from the Apache Foundation ( to compile the source files, build the distribution files, generate the Javadoc documentation, and run the samples. The Ant build tool will make PAGE 3THE JASPERREPORTS ULTIMATE GUIDE working with the JasperReports library easier. Please refer to the Ant documentation for installation instructions. BUILDING THE PROJECT FROM SOURCE FILES Once you have installed Ant, you can compile the source files, generate the Javadoc API documentation, or build the distribution JAR files. To do this, execute the Ant tasks declared in the build.xml file found in the root directory of the project tree. To see details of each available task, launch the ant -p command from the command prompt inside this root directory. RUNNING THE SAMPLES The JasperReports distribution package comes with a complete set of sample applications and reports that show how each individual feature of the library can be used. The samples are in the /demo/samples directory inside the project tree. HSQLDB DEMO DATABASE Some of the samples use data from an HSQLDB demo database supplied in the /demo/hsqldb directory of the JasperReports distribution ( Before running those samples, start the HSQLDB database by going to the /demo/hsqldb directory and launching ant runServer from the command prompt. To look into the database content using a simple SQL client tool, launch the HSQLDB Manager application by invoking ant runManager in the same directory after starting the database. To test a particular sample in the /demo/samples directory, go to the corresponding sample subfolder and launch ant -p from the command line. This displays a short description of what that sample demonstrates as well as a complete list of Ant tasks available for use on the sample’s source files. The following list gives the typical steps for running a sample: 1. Compile the sample’s Java source files by calling ant javac. 2. Compile the JRXML report templates used by the sample application with ant compile. 3. Fill those report templates with data by calling ant fill. 4. View the result with ant view. To export to other formats, simply use commands like ant pdf or ant html. PAGE 4WORKING WITH REPORT TEMPLATES Report templates are standard in reporting applications. They define the layout of the documents that the report-filling process produces. Like other reporting engines, JasperReports uses report templates structured in multiple sections. Each section type has its own characteristics and behavior. Section types include title, summary, page and column headers and footers, group headers and footers, and details. Each section is made of individual elements like lines, rectangles, static and dynamic text fields, images, and charts. Creating a report template is a two-phase process because of how JasperReports evaluates report expressions, also known as formulas. The phases are as follows: 1. The initial report templates are compiled into a more digestible form before being filled with data. 2. Various consistency checks are performed and information for evaluating expressions at runtime is added. The entry point into the JasperReports object model is the class, whose instances represent the source report templates, also called the raw material. These objects are created by using the JasperReports API directly, through parsing of a JRXML file edited by hand, or by using an UI design tool. Once compiled, these report-design objects are transformed into compiled report templates in the form of net.sf.jasperreports.engine.JasperReport objects. Through compilation, the report templates are validated and put into a more read-only form containing attached compiler data that will be used for expression evaluation during the filling process. CREATING REPORT TEMPLATES There are two ways to create report templates:  Creating objects directly using the API  Editing JRXML files using either a simple text editor, an XML editor, or a specialized GUI tool PAGE 6THE JASPERREPORTS ULTIMATE GUIDE The first option is recommended only in case the parent application that uses JasperReports inside the reporting module needs to create report templates at runtime. In most cases this is not needed because the report templates do not need to change with every report execution, and hence static report templates could be used. Only the data used to fill these static report templates is dynamic. However, there are cases when the actual report template is the result of some user input. The parent application might supply its users with a set of options when launching the reports that might take the form of some simplified report designer or wizard. In such cases, the actual report layout is not known or is not complete at design time, and can only be put together after the user’s input is received. The most common use case scenario that requires dynamically built or ad hoc report templates (as we call them) is one in which the columns that are going to be present in a table-like report layout are not known at design time. Instead, the user will give the number of columns and their order inside the desired report at runtime. Developers have to make sure that the applications they create really need ad hoc reports and cannot rely solely on static report templates. Since dynamically built report templates have to be compiled on the fly at runtime, they can result in a certain loss of performance. The second option for creating report templates is to edit JRXML files and use those with the net.sf.jasperreports.engine.JasperCompileManager to prepare them for filling with data. Because they are well structured and are validated against a public XSD when parsed, these files can be easily edited using simple editors or specialized XML editors. REPORT DESIGN PREVIEW The JasperReports library does not ship with an advanced GUI tool to help design reports. It is the iReport project from Jaspersoft which provides a high quality and up-to- date visual designer for creating report templates. However, the library contains a very helpful visual component that lets you preview the report designs as you build them. The net.sf.jasperreports.view.JasperDesignerViewer class is a simple Swing-based Java application that can load and display a report template either in its JRXML form or its compiled form. Even though it is not a complex GUI application and lacks advanced functionality like dragging and dropping visual report elements, it is a very helpful tool. All the supplied samples were initially created using this design viewer. All the supplied samples already have Ant tasks in their build.xml files that will launch this design viewer to display the report templates. PAGE 7THE JASPERREPORTS ULTIMATE GUIDE There are two Ant tasks for each sample report: viewDesign and viewDesignXML. The first one loads the compiled report template that is normally found in the .jasper file. The second one loads the JRXML report template, which is more useful since you can edit the JRXML file and click the Reload button to immediately see the modification on the screen. To preview a sample report template if you have the Ant build tool installed on your system, simply go to the desired sample directory and enter something like the following from the command line: ant viewDesignXML or ant viewDesign By launching this command, you should see the window shown in Figure 2-1. Figure 2-1. Report design preview tool LOADING AND STORING REPORT TEMPLATE FILES Both the and net.sf.jasperreports.engine.JasperReport classes implement the PAGE 8THE JASPERREPORTS ULTIMATE GUIDE interface. This allows users to store their report templates as serialized objects either in their fully modifiable state (JasperDesign objects) or in their compiled form (JasperReport objects). For serializing objects to files or output streams, the JasperReports library offers a utility class named net.sf.jasperreports.engine.util.JRSaver. To load serialized objects, you can rely on the supplied net.sf.jasperreports.engine.util.JRLoader utility class, which exposes various methods for loading objects from files, input streams, URLs, or classpath resources. This utility class has a method called loadObjectFromLocation(String location), with built-in logic to load a serialized object from a specified java.lang.String location received as parameter. If this method is called, the program first tries to see if the specified location is a valid URL. If it is not, it then tries to determine whether the location points to an existing file on disk. If that also fails, the program tries to load the serialized object from the classpath using the specified location as a classpath resource name. The library also exposes methods for parsing JRXML content into JasperDesign objects or for producing JRXML content out of a JasperDesign or JasperReport object. The functionality is located in the following classes:  net.sf.jasperreports.engine.xml.JRXmlLoader  net.sf.jasperreports.engine.xml.JRXmlWriter In certain cases in your application, you might want to manually load the JRXML report template into a object without immediately compiling it. You might do this for applications that programmatically create report designs and use the JRXML form to store them temporarily or permanently. You can easily load objects from JRXML report designs by calling one of the public static load() methods exposed by the net.sf.jasperreports.engine.xml.JRXmlLoader class. This way, report design objects can be loaded from JRXML content stored in a database field or other input stream sources. The library contains utility methods for parsing JRXML into report design objects and vice versa. You can generate JRXML from an in-memory report design object. As shown, sometimes report designs are generated automatically using the JasperReports API. Report design objects obtained this way can be serialized for disk storage or transferred over the network, but they also can be stored in JRXML format. PAGE 9THE JASPERREPORTS ULTIMATE GUIDE You can obtain the JRXML representation of a given report design object by using one of the public static writeReport() methods exposed by the net.sf.jasperreports.engine.xml.JRXmlWriter utility class. COMPILING REPORT TEMPLATES Source report templates, created either by using the API or by parsing JRXML files, are subject to the report compilation process before they are filled with data. This is necessary to make various consistency validations and to incorporate into these report templates data used to evaluate all report expressions at runtime. The compilation process transforms objects into net.sf.jasperreports.engine.JasperReport objects. Both classes are implementations of the same basic net.sf.jasperreports.engine.JRReport interface. However, JasperReport objects cannot be modified once they are produced, while JasperDesign objects can. This is because some modifications made on the report template would probably require re-validation, or if a report expression is modified, the compiler-associated data stored inside the report template would have to be updated. JasperDesign objects are produced when parsing JRXML files using the net.sf.jasperreports.engine.xml.JRXmlLoader or created directly by the parent application if dynamic report templates are required. The GUI tools for editing JasperReports templates also work with this class to make in-memory modifications to the report templates before storing them on disk. A JasperDesign object must be subject to the report compilation process to produce a JasperReport object. Central to this process is the interface, which defines two methods, one being the following: public JasperReport compileReport(JasperDesign design) throws JRException; There are several implementations for this compiler interface depending on the language used for the report expressions or the mechanism used for their runtime evaluation. EXPRESSIONS SCRIPTING LANGUAGE The default language for the report expressions is Java (see the discussion of the language property in “Report Template Properties” on page 42), but report expressions can be written in Groovy, JavaScript or any other scripting language as long as a report compiler implementation that can evaluate them at runtime is available. PAGE 10THE JASPERREPORTS ULTIMATE GUIDE JasperReports currently ships report compiler implementations for the Groovy scripting language (, JavaScript (, and the BeanShell scripting library ( The compiler implementation classes are:  net.sf.jasperreports.compilers.JRGroovyCompiler  net.sf.jasperreports.compilers.JavaScriptCompiler  net.sf.jasperreports.compilers.JRBshCompiler Historically, these compiler implementations used to be shipped as separate samples, but now they are part of the core library. For more details about those report compilers, check the /demo/samples/beanshell, /demo/samples/groovy and the /demo/samples/javascript samples distributed with the project source files. REPORT COMPILERS The report templates can be compiled using the desired report compiler implementation by instantiating it and calling the compileReport() method mentioned previously. Since the most common scenario is to use the Java language for writing report expressions, default implementations of the report compiler interface are shipped with the library and are ready to use. They generate a Java class from the report expressions and store bytecode in the generated net.sf.jasperreports.engine.JasperReport object for use at report-filling time. The Java report compilers come in different flavors depending on the Java compiler used to compile the class that is generated on the fly:      To simplify the report-compilation process, the JasperReports API offers a facade class (net.sf.jasperreports.engine.JasperCompileManager) for compiling reports. This class has various public static methods for compiling report templates that come from files, input streams, or in-memory objects. The facade class relies the report template language to determine an appropriate report compiler. The report compilation facade first reads a configuration property called net.sf.jasperreports.compiler.language to determine whether a compiler implementation has been configured for the specific report language. If such a property is found, its value is used as compiler implementation class name and the facade PAGE 11THE JASPERREPORTS ULTIMATE GUIDE instantiates a compiler object and delegates the report compilation to it. By default, JasperReports includes configuration properties that map the Groovy, JavaScript and BeanShell report compilers to the groovy, javascript and bsh report languages, respectively. If the report uses Java as language and no specific compiler has been set for this language, the report compilation facade employs a built-in fall back mechanism that picks the best Java-based report compiler available in the environment in which the report compilation process takes place. The first reads the configuration property called net.sf.jasperreports.compiler.class to allow users to override its built-in compiler-detection logic by providing the name of the report compiler implementation to use directly. More on configuration properties for customizing report compilation can be found later in this chapter. This facade first tries to see if the JDT compiler from the Eclipse Foundation is available in the application’s classpath. If it is, the implementation is used. The current JasperReports distribution ships the JDT compiler packed in the /lib/jdt- compiler.jar file. If the JDT compiler is not available, the compilation facade then tries to locate the JDK 1.3–compatible Java compiler from Sun Microsystems. This is normally found in the tools.jar file that comes with the JDK installation. If the JDK 1.3–compatible Java compiler is not in the classpath, the fall back search mechanism looks for the JDK 1.2–compatible Java compiler, also from Sun Microsystems, in case the application is running in an environment that has a JDK version prior to 1.3 installed. This is also found in the tools.jar file from the JDK installation. If all these fail, the last thing the fall back mechanism does is to try to launch the javac.exe program from the command line in order to compile the temporarily generated Java source file on the fly. A BRIEF HISTORY OF REPORT COMPILATION All these report compiler implementations are included for historical reasons. In the beginning, JasperReports started with only the JDK 1.2–compatible report compiler. Then the JDK 1.3–compatible report compiler was introduced. But both were slow. This is why the was created, because the Jikes compiler proved to be up to ten times faster than the JDK-based Java compiler. However, compiling reports on the fly (in the cases in which dynamic report templates were required) proved to be problematic, especially in a web environment, because all the aforementioned compilers worked only with files on disk and required a temporary PAGE 12THE JASPERREPORTS ULTIMATE GUIDE working directory to store the generated Java source files and the corresponding class files during the report-compilation process. This is why a new implementation was added —one that relied on the BeanShell library for runtime expression evaluation. BeanShell does not produce Java bytecode and can work with in-memory scripts that it interprets at runtime. With the, deployment was simpler, but expression evaluation was slower and loss in performance was noticeable. The addition of the JDT-based report compiler makes the whole process both faster and simpler to deploy, as it does not require files on disk and its performance is comparable to Jikes. Runtime report compilation is not an issue anymore, and simply putting the supplied /lib/jdt-compiler.jar file in the application’s classpath allows dynamic report template creation without requiring any further settings. CONFIGURATION PROPERTIES TO CUSTOMIZE REPORT COMPILATION Because it is a library, JasperReports offers various mechanisms for letting users customize its behavior. One of these mechanisms is a complete set of configuration properties. The following paragraphs list all the configuration properties that customize report compilation. You can learn more about how JasperReports can be configured in “Configuration Files” on page 272. net.sf.jasperreports.compiler.xml.LANGUAGE Such properties are used for indicating the name of the class that implements the JRCompiler interface to be instantiated by the engine for a specific report language when the default compilation is used through the JasperCompileManager facade The value for such a configuration property can be the name of one of the built-in implementations of this interface shipped with the library as listed previously, or the name of a custom-made implementing class. One can configure report compilers for custom report languages and override the default compiler mappings by setting JasperReports properties of the form net.sf.jasperreports.compiler.language to the desired compiler implementation class names. In particular, the mechanism that automatically chooses a Java report compiler can be superseded by explicitly setting the property to the name of one of the built-in Java compiler classes or of a custom compiler implementation class. Note that the classes implementing the JRCompiler interface can also be used directly in the programs without having to call them through the facade JasperCompilerManager class. PAGE 13THE JASPERREPORTS ULTIMATE GUIDE net.sf.jasperreports.compiler.xml.validation This was formerly known as the jasper.reports.compile.xml.validation system property. The XML validation, which is on by default, can be turned off by setting the net.sf.jasperreports.compiler.xml.validation configuration property to false. When turned off, the XML parser no longer validates the supplied JRXML against its associated XSD. This might prove useful in some environments, although it is not recommended. When working with a Java class generating the type of a report compiler, further customizations can be made using the following system properties, which only apply to them. net.sf.jasperreports.compiler.classpath Formerly known as the jasper.reports.compile.class.path system property, this supplies the classpath. JDK-based and Jikes-based compilers require that the classpath be supplied as a parameter. They cannot use the current JVM classpath. The supplied classpath resolves class references inside the Java code they are compiling. This property is not used by the JDT-based report compiler, which simply uses the parent application’s classpath during Java source file compilation. net.sf.jasperreports.compiler.temp.dir This was formerly known as the jasper.reports.compile.temp system property. The temporary location for the files generated on the fly is by default the current working directory. It can be changed by supplying a value to the net.sf.jasperreports.compiler.temp.dir configuration property. This is used by the JDT-based compiler only when it is requested that a copy of the on-the-fly generated Java class be kept for debugging purposes as specified by the next configuration property, because normally this report compiler does not work with files on disk. This was formerly known as the system property. Sometimes, for debugging purposes, it is useful to have the generated .java file or generated script in order to fix compilation problems related to report expressions. By default, the engine deletes this file after report compilation, along with its corresponding .class file. To keep it, however, set the configuration property to true. PAGE 14THE JASPERREPORTS ULTIMATE GUIDE JDT COMPILER–SPECIFIC CONFIGURATION PROPERTIES The JRJdtCompiler report compiler can use special JasperReports configuration properties to configure the underlying JDT Java compiler. This report compiler collects all the JasperReports configuration properties (the ones usually set in the file) that start with the org.eclipse.jdt.core. prefix and passes them to the JDT Java compiler when compiling the generated Java class to evaluate report expressions. One of the uses of this mechanism is to instruct the JDT compiler to observe Java 1.5 code compatibility. To do so, the following properties should be set: org.eclipse.jdt.core.compiler.source=1.5 org.eclipse.jdt.core.compiler.compliance=1.5 org.eclipse.jdt.core.compiler.codegen.TargetPlatform=1.5 This is demonstrated in the /demo/samples/java1.5 sample distributed with JasperReports. ANT TASKS When the number of different report files that one has to deal with in a project is significant, there is a need for automating repeating or re-occurring tasks that are to be performed on those files. From a design point of view, the most notable operation that needs to be performed on report source files after they are finished and ready to be deployed is the report compilation. Sometimes reports need to be decompiled in order to reproduce their corresponding source files and perform additional design work on them, or when the same modification needs to be performed identically on all reports. For these re-occurring tasks, JasperReports provides built-in ready-to-use Ant task definitions. ANT TASKS FOR COMPILING REPORTS Since report template compilation is more like a design-time job than a runtime one, a custom Ant task has been provided with the library to simplify application development. This Ant task is implemented by the net.sf.jasperreports.ant.JRAntCompileTask class. Its syntax and behavior are very similar to the built-in javac Ant task. The report template compilation task can be declared like this, in a project’s build.xml file: PAGE 15THE JASPERREPORTS ULTIMATE GUIDE taskdef name="jrc" classname="net.sf.jasperreports.ant.JRAntCompileTask" classpath fileset dir="./lib" include name="/.jar"/ /fileset /classpath /taskdef In the preceding example, the lib should contain the jasperreports-x.x.x.jar file along with its other required libraries. You can then use this user-defined Ant task to compile multiple JRXML report template 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 TEMPLATE COMPILATION TASK Following is the list of attributes that can be used inside the Ant report compilation task to specify the source files, the destination directory, and other configuration properties: srcdir: Location of the JRXML report template files to be compiled. Required unless nested src elements are present. destdir: Location to store the compiled report template files (the same as the source directory by default). compiler: Name of the class that implements the interface to be used for compiling the reports (optional). xmlvalidation: Flag to indicate whether the XML validation should be performed on the source report template files (true by default). tempdir: Location to store the temporarily 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 template compilation task supports nested src and classpath elements, just like the Ant javac built-in task. To see this in action, check the /demo/samples/antcompile sample provided with the project’s source files. PAGE 16THE JASPERREPORTS ULTIMATE GUIDE ANT TASK FOR DECOMPILING REPORTS Sometimes it happens that report templates are to be found only in their compiled form. The source report template files might have been lost and we might have only the compiled report template on which we need to make some modifications. In such cases, the Ant task for decompiling report template files that JasperReports provides becomes very handy. It is implemented by the net.sf.jasperreports.ant.JRAntDecompileTask class and its declaration inside a build.xml should be as follows: taskdef name="jrdc" classname="net.sf.jasperreports.ant.JRAntDecompileTask" classpath refid="classpath"/ /taskdefIn the above example, the classpath should contain the jasperreports-x.x.x.jar file along with its other required libraries. This task works similarly to the report compilation task, but it does the reverse operation. The files to be decompiled can be specified using the srcdir attribute for their root folder or, for more sophisticated file match patterns, a nested src tag. The output folder for the generated files is specified using the destdir attribute. This task is demonstrated in the /demo/samples/antcompile sample provided with the project source files. ANT TASK FOR UPDATING REPORTS Although JasperReports always guarantees backward compatibility of report templates when upgrading to a newer version, sometimes tags or attributes in JRXML are deprecated and replaced with newer ones that offer enhanced capabilities. So while the deprecated attributes and tags still work, it is always advisable to use the latest syntax and thus get rid of the deprecation warnings. Upgrading a report template to the latest JasperReports syntax is very easy; all that needs to be done is to load the report and save it again using the API's utility classes, such as the JRXmlLoader or JRLoader and the JRXmlWriter. This operation can be automated for any number of files using the Ant report update task provided by the JasperReports library in the net.sf.jasperreports.ant.JRAntUpdateTask class, which should have the following definition in a build.xml file: taskdef name="jru" classname="net.sf.jasperreports.ant.JRAntUpdateTask" classpath refid="classpath"/ /taskdef PAGE 17THE JASPERREPORTS ULTIMATE GUIDE This task is useful also in situations where the same modification needs to be applied on a number of different report files. The required modifications can be performed using the JasperReport API after the report design object has been loaded but before it is saved again. Custom implementations of the net.sf.jasperreports.engine.util.ReportUpdater interface can be registered with the Ant report update task using nested updater tags, as seen in the /demo/samples/antupdate sample provided with the project. PAGE 18FILLING REPORT TEMPLATES The report-filling process is the most important piece of JasperReports library functionality, because it manipulates sets of data to produce high-quality documents. This is the main purpose of any reporting tool. The following things should be supplied to the report-filling process as input:  Report template (in the compiled form)  Parameters  Data source The output is always a single, final document ready to be viewed, printed, or exported to other formats. The net.sf.jasperreports.engine.JasperFillManager class is usually used for filling a report template with data. This class has various methods that fill report templates located on disk, come from input streams, or are supplied directly as in- memory net.sf.jasperreports.engine.JasperReport objects. The output produced always corresponds to the type of input received. That is, when receiving a file name for the report template, the generated report is also placed in a file on disk. When the report template is read from an input stream, the generated report is written to an output stream, and so forth. The various utility methods for filling the reports may not be sufficient for a particular application—for example, loading report templates as resources from the classpath and outputting the generated documents to files on disk at a certain location. In such cases, consider manually loading the report template objects before passing them to the report-filling routines using the net.sf.jasperreports.engine.util.JRLoader utility class. This way, you can retrieve report template properties, such as the report name, to construct the name of the resulting document and place it at the desired disk location. The report-filling manager class covers only the most common scenarios. However, you can always customize the report-filling process using the library’s basic functionality just described. PAGE 19THE JASPERREPORTS ULTIMATE GUIDE REPORTING DATA The JasperReports library is completely agnostic and makes no assumptions about where the data it uses for filling the reports comes from. It is the responsibility of JasperReports’ parent application to supply this data and handle the output generated by the library. JasperReports can make use of any data that the parent application might have for generating reports because it relies on two simple things: the report parameters and the report data source. Report parameters are basically named values that are passed to the engine at report- filling time. The report parameter values are always packed in a java.util.Map object, which has the parameter names as its keys. As for the data source, there are two different scenarios: Normally, the engine works with an instance of the net.sf.jasperreports.engine.JRDataSource interface, from which it extracts the data when filling the report. The facade class net.sf.jasperreports.engine.JasperFillManager has a full set of methods that receive a net.sf.jasperreports.engine.JRDataSource object as the data source of the report that is to be filled. But there is another set of report-filling methods in this manager class that receive a java.sql.Connection object as a parameter, instead of an expected data source object. This is because reports are usually generated using data that comes from tables in relational databases. Users can put the SQL query needed to retrieve the report data from the database in the report template itself. At runtime, the only thing the engine needs is a JDBC connection object to connect to the desired relational database, execute the SQL query, and retrieve the report data. Behind the scenes, the engine still uses a special net.sf.jasperreports.engine.JRDataSource object, but this is performed transparently for the calling program. The main difference between parameters and the data source is that parameters are single-named values used inside report expressions for calculations or display, while the data source represents tabular data made of virtual rows and columns that the engine uses for iteration during the report-filling process. JasperReports can make use of any application data because the JRDataSource interface is very simple and easy to implement. It only has two methods:  The next() method, which moves the record pointer to the next record in the virtual tabular data PAGE 20

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.