IMPORT JAVA

The Java Interface was added to Genero way back in 2009 in the 2.20 release.  It opened up the wide world of standard and custom Java libraries that you could then incorporate into your Genero application via IMPORT JAVA, as opposed to the lesser and less portable c- extensions available via IMPORT.

If you have never looked at the Java interface, experiment with the documented Examples , or the examples in the Getting Started section.  I would suggest starting off with the simple regular expression (regex) example …

IMPORT JAVA java.util.regex.Pattern
IMPORT JAVA java.util.regex.Matcher
MAIN
    DEFINE p Pattern
    DEFINE m Matcher

    LET p = java.util.regex.Pattern.compile("[a-z]+")
    LET m = p.matcher("abcdef")
    DISPLAY m.matches()
END MAIN

Before we introduced our own regular expression library in Genero 4.00, this example was the flagship example of why you might use IMPORT JAVA.  Rather than writing your own regular expression library, find one that has already been written in JAVA and incorporate it in your Genero application.

Today the flagship example of a Java library incorporated into a Genero application would be the Apache Poi library as illustrated in this example in our Github repository fgl_apache_poi.  Anytime you are thinking of reading or writing to an Excel or Word document, this should be your first option.  With a little bit of magic it also gives you access to the wide range of financial functions that Excel has.

When reading with the Java interface, there are some questions we get asked repeatedly.  There are three limitations that are detailed in the first page of the Java Interface documentation

The Java interface of Genero has the following limitations:

1. It is not possible to use Java generic types such as java.util.Vector, with a type parameter (for example, in pure Java: Vector v = new Vector() ).
2. Database connections cannot be shared between Java and Genero programs.
3. Java graphical objects cannot be used in Genero forms.

… With regards to the third one that gets asked about Java graphical objects.  Genero architecture has a front-end and a back-end.  The Java interface interacts with the back-end fglrun process, not the front-end gdc.exe / gbc.js etc process.

For developers whose first language is Java, using create() instead of new to instantiate a class is something else they might miss and have to adjust to.  The advanced programming section is also useful reading for them to see how Java maps to and is different from Genero BDL.

Java error messages which are typically many lines of a stack dump also throw Genero BDL developers who are used to a one line error message and description.    Typically the main error you hit is resolved by making sure you have all the Java classes needed and that CLASSPATH (the Java environment variable that controls where libraries are loaded, similar to FGLLDPATH) references them all.  One troubleshooting tip is to write a small Java program that will help tell you if you are missing a Java class or if CLASSPATH s set incorrectly.

The final tip for the use of IMPORT JAVA concerns thoughts on system performance.  When using IMPORT JAVA, a Java Virtual Machine (JVM) is instantiated and it will live for as long as the fglrun process it was started with is alive.  This can lead to an unnecessary consumptions of resources if the Java process is not used throughout the lifetime of the fglrun process.  For example if you have a fglrun process that is alive for 15 minutes and the only use of IMPORT JAVA is in a library call at the beginning of the program, that java process will remain alive for the same time as the fglrun process.

What this last tip means is that you may need to consider exposing the Java functionality via a Web Service rather than using IMPORT JAVA.  Wether this is a 100% Java Web Service or is a Genero Web Service program that uses IMPORT JAVA is up to you.  Alternatively you might break your program into parts and use RUN to start a short-lived program that contains the IMPORT JAVA.  The point is to only have  the number of JVM actually needed rather than having many JVM sitting idle consuming resources.  We see a similar performance hit with Genero Report Writer which is written in Java, hence why you get better performance with Distributed Mode for Genero Report Writer .