Using VSCode and Gradle for z/OS Java Development

Image for post
Image for post
VSCode image, from the official VSCode website

This article outlines my journey to achieve a clean solution for Java development (including testing and code coverage) on a z/OS machine with a popular IDE.

Around a month back, I got the itch to try something new. VSCode was a very shiny toy that I’ve been hearing about from my cloud development friends, so I started to try it out for my open source Python development. I fell in love! Naturally, I wanted to bring it to work.

Around the same time, I wanted to start running automated test cases for z/OS Java code… with the elusive code coverage. The tool I ended up using was Gradle, mostly because it utilizes Groovy and I didn’t want to bother with Ant XML.

What is VSCode?

VSCode is just another one of those modern IDEs, but it’s pretty fast at loading files and has a ton of open source extensions. Before VSCode, I was using Atom for open source development, but quite honestly VSCode is lightyears faster.

Recently there have been z/OS extensions popping up in VSCode with all of the cool work that ZOWE is doing, so it was also an opportunity to hop on the early adopters train. Wazi is also making some very cool extensions!

What is Gradle?

Gradle is a popular build tool, with some cool automation functionality. I ended up needing it for a few things, which we’ll drill into throughout the article.

The Goals

For this project, I wanted to achieve a few things.

  1. I wanted to edit locally, but my code needed to be on z/OS for testing before committing. There’s a few ways to get code over to z/OS, but I wanted a clean solution in a single command (or no command at all). Dragging over files in an FTP client, sending over a tar file, committing to Git before testing on z/OS, and remote editing were existing solutions that I wanted to avoid.
  2. I wanted to be able to build both locally and on z/OS. There’s nothing worse than moving your code over to a remote system, just to find out there’s a small compile error you missed. Due to this, I want to be able to build my code before sending it over for testing.
  3. I wanted code coverage. This has eluded me for a few months, and I figured it was finally time to get my beloved code coverage. It’s an extremely useful tool to isolate weak parts of your programs that need additional tests.
  4. I wanted to use VSCode. The z/OS IDEs like IBM Developer for z Systems are better for this sort of work, but I wanted to use the same tool that I use in my open source development.

The reality for these goals is that z/OS is just another remote machine, just like Ubuntu or Windows servers. So let’s treat it that way!

The Workflow

My first task was to be able to edit my code locally, and then get it over to z/OS in a single command for testing.

Ultimately, I wanted my end-to-end workflow to be the following:

  • Implement a feature
  • Build my code (gradle build)
  • Move it to z/OS (gradle ftp)
  • Build on z/OS (gradle build on Z)
  • Test on z/OS (gradle test on Z)
  • Commit it!

I did all of this in Gradle. Mostly because I just threw a dart and it landed there, feel free to use your favorite tool (Groovy, Ant, Maven, etc). Theoretically, you could even apply this to COBOL and other mainframe languages using Groovy and IBM Dependency Based Build… but that’s an article for another day.

Installing VSCode

Simply download it here, and run the installer. After installing, feel free tocheck out some of the z/OS extensions like Enterprise COBOL for z/OS. There’s more and more popping up!

Installing Gradle

Getting Gradle going on your local machine is pretty trivial, just install it. However, getting it going on z/OS is something a little different.

Currently, the Gradle daemon is not supported on z/OS. There’s a lot of codepage issues, and it just doesn’t work. Thus, you have two options.

  • Turn off the Gradle Daemon
  • Use the Gradle version without the Daemon

I chose #2, because this was mostly an exploratory solution and I ran into issues on my first attempt to turn off the daemon. To do this, you’ll need to grab Gradle 2.4, add it to your path, and you’re good to go.

Setting up the local Gradle processes

As stated earlier, I only need a few things for my local machine.

  • Editing my code with VSCode (trivial, same as any other IDE)
  • Building my code locally (Mac, Windows, etc)
  • Moving my code to z/OS

Building my Code

Gradle is the tool I used for building and testing, a sample Gradle script looks a little like the following:

There’s obviously a ton of redacted stuff here, but you can mostly fill in the blanks. The most important part is that we can’t use the Maven repository for resolving dependencies, because we’re on z/OS and will not be able to resolve the URLs on a standard machine for security purposes. Thus, we need to use flatDir’s and explicitly state our dependencies. Don’t forget to download the JAR files (hint: you can download them from the Maven repository manually)!

This can be very frustrating if you’re used to just defining a common tool and having MavenCentral resolve all of the dependencies, but it’s the price we pay for security. The solution would be to whitelist the URLs.

Code Coverage

For code coverage (jacocoTestReport), you’ll need the following dependencies (and their respective JAR files):

Those were super fun to find without using Maven to automatically resolve… not. By running the jacocoTestReport task, you’ll be able to generate code coverage reports for your source code.

Moving Code

To move code, I simply created an FTP task for Gradle.

You’ll need the following dependencies:

Usage

With the file we’ve built, we’re now able to use a couple of commands.

  • gradle build (builds your code)
  • gradle ftp (moves your code over to z/OS)

And we’re done with the local side!

Setting up the z/OS Gradle Process

There’s not much setup here past installing Gradle on z/OS, the previous script is the same script you’re going to use on z/OS.

You’ll use the same commands to build (minus the FTP command), and be able to view code coverage reports from your test cases.

Going Further

In the future, it would be fun binding everything into a single command- building my code locally, sending it to z/OS if successful, and building/testing there.

I’m certain that it’s possible, I just haven’t had the time yet.

Conclusion

From my past couple of articles, it should be obvious that z/OS is just another machine to execute code on- except that it’s very fast. Using the tools you want takes a little extra work, but it helps you understand those tools at a deeper level.

Hopefully this helps you out with exploring new options with z/OS; the possibilities are endless.

If you liked this, feel free to check out some of my other articles.

Till next time!

Written by

Software engineer, gamer, and foodie. Currently working at IBM writing mainframe modernization tools.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store