What performance improvements does jasper_reports NG provide?

It starts a Java process automatically with the first report, avoiding the cost of restarting the Java virtual machine each time. Reports using the XML interface can also be up to 10% faster by using CSV files instead of XML.

How are translatable fields displayed in reports?

By default, they are generated in the language of the user running the report. If the field is a java.lang.Object , a specific locale such as caES , or the partner’s language, can be requested.

What syntax can translate parameterised text?

The tr function translates text and accepts parameters; trn defines singular and plural forms based on a quantity.

What limitations does I18nGroovyCompiler have?

Reports must use Groovy as their language, and they cannot be previewed inside iReport.

jasper_reports: Performance and Localization Improvements|NaN·tic

Right after the release of the first release candidate of Koo, we've committed a bunch of exciting changes in the jasper_reports module. Those changes can be classified in two separate areas: performance and localization.

Performance

In the performance area, we've created a Java process, started automatically when the first report is executed, that avoids the overhead of starting the Java Virtual Machine each time a report has to be printed. The other performance improvement affects only reports using the XML interface, which can benefit from up to a 10% speed increase thanks to the use of CSV files instead of XML. It is fully compatible and does not change anything when users create new reports.

Localization

It is now possible to use translatable fields, such as product names and country names, in any language. By default, the XML interface creates translatable fields in the language of the user executing the report. If the field is assigned the java.lang.Object type instead of java.lang.String in iReport, the report can use:

$F{product_name}.get( "ca_ES" )

If the report is an invoice, for example, it has a relation to the party. In that case, you can use:

$F{product_name}.get( $F{partner_language} )

If a translation is not available for that language, the default translation is used.

We also decided to extend JasperReports' localization features. The report designer can translate text with:

tr("This is the text I want to translate")

or with parameters:

tr("{0} out of {1} think this translation system is great!", $F{positive},$F{total})

Plural forms are also supported:

trn("One person", "{0} people", $F{people})

Almost all functions in java gettext have been implemented, including versions with configurable locales. For example:

tr( new Locale("ca", "ES"), "This text will be translated into Catalan even if the default report locale is in german!")

The jasper_reports/java directory contains two scripts for extracting these texts:

jrxml2pot: extracts report texts into a .pot file.
po2properties: converts a translated PO file into a .properties file.

The report directory should contain:

text superreport.jrxml superreport_ca_ES.properties superreport_de_DE.properties ...

If a translation is unavailable, the original text is printed.

This mechanism can be integrated into modules and translated through Launchpad. Because JasperReports lacks infrastructure for this kind of task, we had to reimplement the GroovyCompiler, creating I18nGroovyCompiler. This means that:

Groovy must be used as the report language.
Reports cannot be previewed inside iReport.

Update: Recent tests have shown that some reports take less than half the time they took with the XML backend, so performance gains are significant depending on the report.