What I learned from the Jenkins & Java 10+ Hackathon

With the Java 8 EoL data looming, the focus was on the current available version of Java, Java 10. Java 10 offers some nice new features and APIs, not least improved docker container integration. We learned from Paul of a number of projects with Java 10 migration success stories including Elasticsearch, Kafka & Netty.

At the beginning of the hackathon week, the Jenkins Pipeline feature would crash out when using Java 10. This was resolved with a number of fixes including the upgrade of the ASM library. Then it was nice to see things up and running with Java 10.

The first steps were to do some exploratory testing using Jenkins with Java 10 via Docker, thanks to Oleg for providing clear instructions. This was boringly straightforward as most things worked and we only found one issue to report. Next to try to get some patches in, we needed to set-up a dev environment. The live session gave us what we needed to set up a plugin or core dev environment. One open question we had was whether Jenkins has semantic versioning and API tools to help identify when you might be breaking backwards compatibility. Overall it was straightforward to get a dev environment up and running.

The next step was to find an issue which we could help resolve. Many of the Java 10 issues were related to 'Illegal reflective access' from various plugins or third-party libraries. However after investigating a couple, removing these warnings required a good architectural knowledge of the plugin or core code itself. In the end we decided that messing around with classloaders or attempting to upgrade version of jdom was not one for the newbies.

Instead we looked at removing reflection in cases of isAccessible calls. We found the ProcessHandle api very useful and a good replacement for some misuse of reflection, and even better it made the code work on Windows too. Mandy also pointed us to look at the Lookup api as possible alternate to findClass calls.

Using new APIs is all well and good but presents a problem when you want to maintain backwards compatibility with Java 8. Hence the need for some sort of multi-jar solution - Nicolas De loof proposed one such solution for multi-release jars with Maven for this case.

The Java Signal API is being deprecated, but so far no replacement APIs are available for signal handling. Jenkins makes use of the Signal APIs so a big question for the Jigsaw team was whether this would be replaced going forward. Kohsuke pointed out how it is important for Java to maintain this UNIX like behaviour as it shouldn’t matter to end users that Jenkins is written in Java. It seems these APIs will be replaced in due course, they just aren’t there right now.

It was great to have the discussions with the Jigsaw team. They reminded us how they need to know the Java use cases out there and how their team uses these to feed into their development process. In turn, the hackathon had Jenkins community members participate, for instance easy-jenkins was up and running with Java 10 by the end of the week. The hackathon had a great feeling of community spirit and was a reminder why collaborations with communities and also between different communities can be powerful and fun for all involved.

At the end of the week Jonah and I were both happy that we made our first Jenkins contributions (which were reviewed and merged quickly). Thanks to all who participated and made it highly enjoyable, especially Oleg for great organization. I look forward to the next one!