Skip to main content

Managing Java versions

Abstract

All Bitrise virtual machines have Java 8, Java 11, and Java 17 pre-installed. The default version is Java 17 but you can switch versions at any time.

By default, every Bitrise stack comes with Java 11 pre-installed and ready to use. If you do not switch to another version, your build will use Java 11.

In addition to 11, we have two more Java versions pre-installed on all stacks:

  • Java 8

  • Java 17

You can switch between the versions at any time. You can also install a different Java version (for example, 14).

Potential issues with Java versions

Using a new Java version, or switching Java versions during a build might cause unexpected issues:

Setting Java version with the Set Java version Step

Each Bitrise stack has three different Java versions pre-installed: 8, 11 (the default version), and 17. You can easily switch between the different Java versions with our Set Java version Step. The Step allows you to set the global Java version of the virtual machine that runs your build.

Installing a new Java version

This Step cannot install any Java version. It can only switch between the versions that are pre-installed on our stacks. If you want to install a Java version that is not available on our stacks by default, check out Installing a Java version on an Android stack.

  1. Add the Set Java version Step to your Workflow. We recommend setting it as the first Step of the Workflow.

  2. Find the Java version to be set globally for the build input.

  3. Set it to the version you need.

    The options are:

    • 8

    • 11 (the default value)

    • 17

Example 1. YAML example

In this example, we're setting the Java version to 17 in the bitrise.yml file.

primary:
  steps:
  - set-java-version@1:
      inputs:
      - set_java_version: '17'

Setting Java versions with a Script Step

If you don't want to use the Set Java version Step to change the default Java version on the build machines, you don't have to: you can accomplish the same thing using a Script Step.

Our Android & Docker stacks run on virtual machines with Ubuntu, while our Xcode stacks run on macOS. The process is a little different for the different stack types but on all stacks, switching to a different Java version requires three things:

  • Setting Java itself and the Java compiler to the selected version.

  • Setting the JAVA_HOME Environment Variable with the export command.

  • Storing this Environment Variable with envman so it can be accessed by all Steps in your Workflow.

Steps and Env Vars

You need envman because without that, Steps can’t access each other’s Environment Variables. If you only set the Java environment for one Step, but do not store it with envman, the other Steps will use the default Java environment, Java 11.

On macOS-based stacks

  1. Open your app on Bitrise.

  2. Click the Workflows button on the main page.

  3. On the Workflows & Pipelines page, find the Workflow you need.

    workflow-and-pipelines.png
  4. Click the edit-webhook.svg button next to the name of the Workflow.

  5. Add a Script Step to the Workflow before any Step that uses Java in any way.

    The simplest way to do it is to place it as the first Step of the Workflow.

  6. Add one of the following commands to the Script content input of the Step:

    • To set the global Java version for the build to Java 11:

      jenv global 11
      export JAVA_HOME="$(jenv prefix)"
      envman add --key JAVA_HOME --value "$(jenv prefix)"      
    • To set the global Java version for the build to Java 8:

      jenv global 1.8
      export JAVA_HOME="$(jenv prefix)"
      envman add --key JAVA_HOME --value "$(jenv prefix)"   
  7. Click Save at the top right corner.

On Ubuntu-based stacks

  1. Open your app on Bitrise.

  2. Click the Workflows button on the main page.

  3. On the Workflows & Pipelines page, find the Workflow you need.

    workflow-and-pipelines.png
  4. Click the edit-webhook.svg button next to the name of the Workflow.

  5. Add a Script Step to the Workflow before any Step that uses Java in any way.

    The simplest way to do it is to place it as the first Step of the Workflow.

  6. Add the following commands to the Script content input of the Step:

    • To set the global Java version for the build to Java 11:

      sudo update-alternatives --set javac /usr/lib/jvm/java-11-openjdk-amd64/bin/javac
      sudo update-alternatives --set java /usr/lib/jvm/java-11-openjdk-amd64/bin/java
         
      export JAVA_HOME='/usr/lib/jvm/java-11-openjdk-amd64'
      envman add --key JAVA_HOME --value '/usr/lib/jvm/java-11-openjdk-amd64'      
    • To set the global Java version for the build to Java 8:

      sudo update-alternatives --set javac /usr/lib/jvm/java-8-openjdk-amd64/bin/javac
      sudo update-alternatives --set java /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
             
      export JAVA_HOME='/usr/lib/jvm/java-8-openjdk-amd64'
      envman add --key JAVA_HOME --value '/usr/lib/jvm/java-8-openjdk-amd64'
      
  7. Click Save at the top right corner.

Installing a Java version on an Android stack

If you need a Java or JDK version which is not installed on our Android stacks, follow this guide. The example below will install Java/JDK 1.14 with a Script Step. You can adapt it to the version of your choice.

  1. Open your app on Bitrise.

  2. Click the Workflows button on the main page.

  3. On the Workflows & Pipelines page, find the Workflow you need.

    workflow-and-pipelines.png
  4. Click the edit-webhook.svg button next to the name of the Workflow.

  5. Add the Script Step to your Workflow.

  6. In the Script content input of the Step, add your script:

    The example below installs Java 14 but feel free to replace the openjdk-14-jdk and java-1.14.0-openjdk-amd64 parts with your version of choice.

    #!/bin/bash
    set -ex
       
    add-apt-repository -y ppa:openjdk-r/ppa
    apt-get update -qq
    apt-get install -y openjdk-14-jdk
    update-java-alternatives -s /usr/lib/jvm/java-1.14.0-openjdk-amd64
    echo "done"    
  7. Start a new build. This Script Step can be the very first Step in the Workflow, as it does not depend on anything else.