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:
- ILE RPG calls Java
- Java calls ILE RPG
- 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!
Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at
MC Press books written by Joe Pluta available now on the MC Press Bookstore.
 |
||
 |
|
Developing Web 2.0 Applications with EGL for IBM i Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform. List Price $39.95 Now On Sale
|
|
||
 |
|
WDSC: Step by Step Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction. List Price $74.95
Now On Sale
|
|
||
 |
|
Eclipse: Step by Step Quickly get up to speed and productivity using Eclipse. List Price $59.00
Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online