Java is still one of the most popular languages, with a huge base of open-source software, and you should know how to take advantage of it.

It's not surprising that two of the most popular programming languages are two of the oldest: C and Java. And while both may be waning in popularity (with Python looking to become the king of the programming hill), there's no denying that Java provides a huge ecosystem of excellent open-source functionality. As an example, I recently had the opportunity to write a streamlined wrapper around the fantastic HSSFR4 service program by Scott Klement, which in turn provides access to the Apache POIJava code that creates and maintains Excel spreadsheets. While I may get an opportunity to write about that in more detail, first I'd like to talk a little more about the basics of using Java.

ILE RPG and Java

If you think about it, there are really three ways for RPG and Java to interact:

1. ILE RPG calls Java
2. Java calls ILE RPG
3. The two interact via a queueing mechanism

And to be a bit more complete, you can replace RPG with any ILE language because the program call mechanism is the same. It's been my experience that Java calling RPG is a little easier than vice versa, while using a queueing mechanism like a data queue is more robust and also makes it possible for Java to communicate with OPM programs. However, for this particular use case, in which we just want to take advantage of an existing set of Java code, calling Java from RPG is the simplest answer.

Complications and Complexities

I'm not going to spend much time on the basic syntax of calling Java; if you want more background and details, start with the IBM documentation. The techniques have been around for decades, since V5R1; you can go back to a great article by Shannon O'Donnell. Instead, I want to talk about some of the complications that surround using Java on the IBM i.

The most important thing to understand is that every job that invokes Java gets its own Java Virtual Machine (or JVM) but that a job gets only one JVM, and that JVM is started on the first call and cannot be changed. Once you start the JVM, that's the one you're using until the job ends. Why is this an issue? Because one of the other complexities of Java on the IBM i is that you can have multiple Java runtimes installed on the machine—not only different Java versions, but also different architectures (32-bit vs. 64-bit). If everybody uses the same Java version, then it's not a problem. But if you need different Java versions for different purposes, you'll have to be very careful about how you start your JVM.

I ran into this specific issue when my spreadsheets started getting larger and larger; I finally ran out of heap space (basically, the Java form of an out-of-memory error). As it turns out, the default Java version on my production machine is 32-bit, which limits you to a total heap of 2GB. In order to get a larger spreadsheet, I needed to go to a 64-bit JVM. So I had to research my options.

It turns out that you can change your Java environment using system settings, but the technique to implement those settings is not consistent. Some are systemwide; some are only for a specific job; some are only for a specific user. Short of programming, the way to change your JVM requires two separate and not particularly intuitive procedures.

Changing Your Java Version

Which version of Java you run depends on which Java Development Kit (JDK) you use. The default JDK depends on your current version of IBM i. Version 7.3, for instance, defaults to 32-bit version of IBM Technology for Java (IT4J) 8.0, while for IBM i 7.4, the default is the 64-bit version. Regardless of your IBM i version, though, you can override the JVM that a job will use by specifying the JAVA_HOME environment variable. Change the variable before you try to run your first Java code and it will force you to the correct Java runtime. For example, to use the 64-bit version of Java 1.8, I execute this command:

ADDENVVAR ENVVAR(JAVA_HOME) VALUE('/QOpenSys/QIBM/ProdData/JavaVM/jdk80/64bit')

         LEVEL(*JOB)

If the value already exists, you'll have to remove it using RMVENVVAR or change it using CHGENVVAR. More important, though, is the keyword LEVEL. If you leave it at the default of LEVEL(*JOB), the environment variable will affect only your job. If you specify LEVEL(*SYS), it will affect all subsequent jobs. I wanted to avoid that because I didn't want to affect other jobs that might be relying on the default runtime. More information on the various JDKs and how to select them can be found in this IBM article.

Changing Your CLASSPATH

CLASSPATH is another environment variable that can be set prior to calling a Java class. Much the same way that you can set the JDK version, you can also set the CLASSPATH. Since it's an environment variable, you can set it for your job or for the entire system. Find out more here.

Changing Other Properties

Changing your Java version and CLASSPATH using environment variables is relatively simple. Since there is an option that can be job-specific as opposed to systemwide, I can control the setting on a per-job basis. A lot of the Java work I do is batch-oriented, so changing environment variables is a good solution.

Other properties, though, aren't quite as easy to address. While you rarely to need to use runtime arguments when starting your JVM, when you do need to change one there's no way around it. What started me on this journey of discovery was just such a case: I had to change the maximum heap size. When you start Java from a command line (or from Qshell), you can include runtime argument –Xmx, which allows you to specify the maximum heap size. In my case, I needed to increase the default of 2GB to 4GB, so I needed a way to specify the value –Xmx4G when starting the JVM. There is a way to do it, but it's not intuitive to us green-screen folks and it also has the unusual characteristic of being user-specific. That means that I cannot submit two jobs with different JVM values without careful runtime manipulation.

The technique requires the use of a text file in your home directory, or more precisely the home directory of the user profile of the job running Java. The file must be called SystemDefault.properties, and in it you can specify runtime properties that will be used by the JVM. The final complexity is that if you need to use an argument other than those that start with –D, you need to use a special syntax for this file that makes use of the #AllowOptions keyword. And of course, the option I need (-Xmx4G) is one of those, so I had to learn that nuance.

Is There an Easier Way?

We've seen how to change the runtime characteristics of your JVM, but it requires two different techniques. One is specific to the job, and one is specific to the user. For the latter technique, you will have to change the SystemDefault.properties file in your home directory every time you want to run with a different set of properties. What's the way to get around that? In the next article, I will show you a way to start the JVM yourself programmatically with whatever properties you need. Stay tuned!