This whole blog has been very RPG centric so far. But some of you also know that I also do some Java programming (and also some Node.js+TypeScript from time to time). Lately I got involved into some Java projects which also include IBM i as a potential target platform.

Java on IBM i has a long history … not always with the best results. Java performance on IBM i was not very good at the start but has improved drastically so that you probably don’t have to worry too much about any differences in runtime to other platforms. But that may depend on your requirements. If every microsecond counts you might be very picky about frameworks, the JRE and the platform it runs on.

My opinion on that is that Java performance on IBM i for the SMB market is more than sufficient. But as IBM i is not only used in the midrange market but also in the high end of computing side-by-side to main frames things may look different in these situations.

But let us stay in the SMB market.

Java on IBM i

The Java Runtime Environment OpenJ9 can be installed via yum which will give you a JRE 11 on IBM i. Just recently the new long term support release of Java version 17 has been released. Hopefully Java 17 will soon come to the IBM i platform so that all the new nifty features like the new Record type can be used.

Batch Processing on IBM i

The batch processing on IBM i was always the domain of RPG and CL. Java didn’t have any say in it so far. But I think with the latest Jakarta EE Batch specification to have the same feature set in RPG or CL you would have to do some serious development work.

Some of those features are:

  • splitting up work into multiple threads (either splitting up the items or the work flow)
  • reusing and mixing of predefined steps
  • declaratively defining the workflow (in XML)
  • restart jobs on failure at last failed transaction
  • job history (runtime, completion status, …)
  • listener interfaces (equivalent to exit points)

It is not that those features are not doable in RPG or CL. In fact I think they are all doable in RPG but they are not available by default and most RPG programs have not been written with those features in mind.

Jakarta EE Batch + DIY

I have searched for some time for a good framework for batch processing in Java but have not found a package or product which supports everything I envisioned for my batch application. So I will have to put the pieces together by myself.

Jakarta EE Batch looks like a good spec for batch processing in Java and JBatch implements it nicely. The good thing is that I can use all the common Jakarta EE annotations and don’t have to learn a completely new framework or approach (like Spring) because I already got enough on my plate. So using the already widely used and supported approach and style is very convenient for me. Jakarta EE Batch also covers all the batch features I need.

Note: Yes, Spring Batch has influenced the development of Jakarta EE Batch a lot but it is not the same. Jakarta EE Batch is also influence by some other frameworks and platforms.

I could have just sticked to JBatch and be done. But there are so many ways and frameworks which make my life easier like CDI, MicroProfile Config, etc … which I also wanted to use. As I haven’t found any prepackaged solution I just package it myself. So it is

JBatch (Jakarta EE Batch) + Weld (CDI) + SmallRye Config (MP Config) + JDBI (database access)

Results

With this stack it is not only easier to write batch programs in Java but also has a pretty decent performance. One test case was to process a data set of 500k records from one table and update about 25k records (record by record) in another table.

This was executed in a breeze by the RPG program in about 4 seconds. But the Java program did also not bad at all with 6 seconds (not taking into account the ramp-up time of the JVM and of the frameworks). You can argue now that the Java program took 1.5 times longer to process the data but the table layout favored more the RPG style of execution as the data set to be processed could not be selected by any index because of the way the data was stored (f. e. dates stored as numbers in the format ddmmyyyy :( ).

So in different cases Java might actually be faster than RPG. But execution time is not always the most important factor. If some approach is fast enough other criteria might be much more interesting, f. e. low maintenance, available developers, active community, fast SDLC, future safety, … just to name a few.

Cons

Some things might be implemented in an easier way. For example the creation of the data source is done manually. This might be done automatically with just some configuration entries, like in Helidon.

Also the dependency injection is not (fully) working in any class which is directly part of the JBatch process, like any ItemReader or ItemWriter as these are not created by Weld but by JBatch and thus don’t fully support CDI yet.

Helidon

Helidon is a micro service framework from Oracle. It comes with everything you need in the micro service world. But it can also be used as a one-stop-shop for all those rudimentry things like CDI, data sources, etc. you need or are useful in a batch program. Helidon 2.x does not support the new jakarta namespace but sticks to the javax namespace for the java enterprise packages. So it does not work with IBM JBatch 2.x because starting with the 2.0.0 version IBM switched to the jakarta namespace.

But you can use Helidon with the JBatch 1.0.3 version. To get all the good stuff of Helidon you would probably need to use helidon-microprofile-cdi as a parent Maven artifact in your project. That artifact has most things included but the web server which you probably don’t need in your batch program. The result is a stripped down Helidon server which you can extend by adding Helidon extensions.

Apache BatchEE

The Jakarta EE Batch implementation placed under the Apache Geronimo project also looks very promising and comes with some additional features like a management UI for running batch processes. But the project does not seem to be very active and so I am sticking with JBatch from IBM.

Example

Actually I wanted to include an example application in this post but this one is already long enough as it is so the JBatch example application be featured in another post.

If somebody is successfully using any other Java based solution I would gladly like to here about it.

Happy batching!

Mihael