Bitrise step or configuration for switching Java version

Description of the feature request

For a long time most of the Java eco system coalesced around JDK8 (certainly in the mobile space). However that time is now over, with tools like Gradle moving to a JDK11 minimum.

While Bitrise already took the step to preinstall JDK11, it is not the default. This is OK, since there is a reasonable chance of breaking things. Bitrise also provides a helpful guide on how to use a script step:

While that helps, it’s still somewhat esoteric and antithetical to the simplicity of Bitrise. Common actions should be a configuration value or be should at least be in the step library.

Use case / for what or how I would use it

Easily set up new workflows for iOS (tools like Kotlin/Native in this case) and Android apps that require JDK11.

Thank you! I will enter this into our db for evaluation.

And you are correct! Both versions were provided on the stack due to various things breaking. We wanted to allow our users to move forward without breaking what was already there!

As you indicated, we do provide scripts that can be included in your workflow to switch to Java 11 so we hope that is relatively easy to use. But I do agree that a step would be more convenient and just a bit “cleaner” !

I would like to add that the lack of this feature caused us (and probably many others) problems recently.

The Bitrise recommend script for changing Java versions did not work correctly on macos BigSur. (jenv global 11 should be used instead of jenv global system), so when going from Catalina to BigSur it entirely breaks using java.

Not only did this cause build issues that had to be debugged, we now have to go and change this script in all our configs.

I don’t blame Bitrise for an error in a script (happens to all of use), but I feel this is kind of the point of Step. With the feature of automatic version updates for steps (really appreciate this!) , it would have caused us no pain.

Likewise, if it were part of the image selection, the problem would never even have occured.

To be honest having to deal with this has felt less like using BitRise, and more like using self hosted CI or some lesser CI provider. I’m aware we could have made our own step for this, but again, not having to mess around with elemental build tools (stable Android tooling now requires Java 11!) etc. is one of the reasons we appreciate Bitrise normally.

For those finding this topic in the future or following it, there have been 2 developments: