Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Add official Java 15 support #5836

Closed
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 12 additions & 4 deletions .github/workflows/build.yml
Original file line number Diff line number Diff line change
Expand Up @@ -8,8 +8,12 @@ on:

jobs:
build:
runs-on: ubuntu-18.04

runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, macOS-latest, windows-latest]
java: [ '11', '11.0.3', '15', '15.0.5']
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are versions specified twice, once as generic and once with a specific minor version?

This will 2x the build verification time, thus the wait time between push and "PR is mergeable".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To check if the supported version at the time of configuration works and also the lastest java sub version

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The build verification time just increased from 9 to 12 min as most of the builds run in parallel.

name: Test Java ${{ matrix.Java }}, ${{ matrix.os }}
steps:
- uses: actions/checkout@v2
with:
Expand All @@ -20,9 +24,8 @@ jobs:
- name: Set up JDK
uses: actions/setup-java@v2
with:
java-version: '11'
java-version: ${{ matrix.java }}
distribution: 'zulu'
cache: 'gradle'

- name: Grant execute permission for gradlew
run: chmod +x gradlew
Expand All @@ -32,3 +35,8 @@ jobs:

- name: Build with Gradle
run: ./gradlew build

- name: Print Dependency Verification Report
if: ${{ failure() }}
run: cat build/reports/dependency-verification/*/*.html
shell: bash
2 changes: 1 addition & 1 deletion apitest/docs/api-beta-test-guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ option adjustments to compensate.

**Shell**: Bash

**Java SDK**: Version 10, 11, or 12
**Java SDK**: Version 10, 11, 12 or 15

**Bitcoin-Core**: Version 0.19, 0.20, or 0.21

Expand Down
4 changes: 2 additions & 2 deletions desktop/package/package.gradle
Original file line number Diff line number Diff line change
Expand Up @@ -7,8 +7,8 @@ task jpackageSanityChecks {
description 'Interactive sanity checks on the version of the code that will be packaged'

doLast {
// Enforce JDK 11 for compiling and building
assert JavaVersion.current().isJava11(): "JDK 11 is required"
// Enforce JDK 15 for compiling and building
assert JavaVersion.current() == JavaVersion.VERSION_15: "JDK 15 is required"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you want to enforce v15, or also allow v15?

If enforce

  • this means binaries will be compiled with v15 (not just jpackage-d)
  • then we should also enforce v15 for development (i.e. not allow anything below, like v10 or v11)

If also allow

  • I can look into the right syntax using Gradle toolchains, as cbeams suggested

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think to have the choice would be better as long as we don't support any other LTS java version.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cd2357 wrote:

Do you want to enforce v15, or also allow v15?

I'm not sure the distinction between allowing and enforcing is really meaningful in the context of using Gradle's toolchain support.

If we declare that the build should run against a given toolchain, e.g. JDK 15, that's what's going to happen, in every case, unless the developer changes the line of code in the build file making that declaration.

So I'd think we want to just pin the build to JDK 15. That'll reduce the CI build matrix and associated times considerably, as it'll just be about building on JDK 15 across the different major OS / architectures.

Then we just ratchet up the toolchain version every time we're ready to make the jump to JDK 16, 17, etc. And by the way, as per #5835, we're not ready for that move yet!

@ripcurlx wrote:

we don't support any other LTS java version

What does "support" mean here? I mean we ship a specific JRE version in our packaged binaries, and that's it, right? Would it have any meaning to say we "support" any other JRE than the one we ship with the app? I might be missing something here...

Copy link
Contributor

@cd2357 cd2357 Nov 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is indeed confusing.

From a birds-eye view, there are three (actually now four) independent "Java versions" we're dealing with:

1. The (local) build JDK

  • This is the Java version used by devs to compile, develop and test the codebase locally
  • this can be anything from JDK 11 and up
  • Depends on what devs have installed locally, not explicitly checked or enforced anywhere (but code only compiles with v11 and up)

2. The (GitHub) build JDK

  • This is the Java version (matrix of versions) used to build on GH
  • It is defined in build.yml L15 of this PR to be v11, 11.0.3, v15, v15.0.5 (before this PR, it was only v11)
  • Goal is to see if the code compiles and tests run for these versions

3. The (release packaging) build JDK

  • This is the JDK available on the machine that creates the release binaries
  • It is used to compile and build the release Bisq jars
  • It's currently specifically defined to be JDK 11
    assert JavaVersion.current().isJava11(): "JDK 11 is required"

    (changed by this PR to v15)

4. The (release packaging) jpackager JDK

  • Defined at
    Map jdk15Binaries = [
  • It is used exclusively to create the platform-specific release binaries (jpackager from earlier JDKs failed for various reasons)
  • This also determines the JRE included in the OS-specific installers and binaries (currently JRE 15)
  • It does not compile or build any jars, instead uses the jars previously compiled in step 3 above

As far as I understand, we've been using JDK 11 pretty much everywhere (except for jpackager and delivered JRE).

This PR, according to ripcurl's comment above, would extend the versions 1-3 above to support both JDK 11 (LTS) and JDK 15 (non-LTS).

I think this is also what ripcurl means with "as long as we don't support any other LTS java version" (next LTS is JDK 17, which AFAIK we don't support).


Update: As far as I can tell, the Gradle toolchain would at most specify the version used for 1-3 above. For releases, the jpackager would still need to be v15, which right now also specifies the delivered JRE.

A jpackager option exists to tell it to package a specific JRE version in the resulting binaries, but it didn't work in my last tests:

// TODO For some reason, using "--runtime-image jdk-11" does NOT work with a v15 jpackage, but works with v14


executeCmd("git --no-pager log -5 --oneline")
ant.input(message: "Above you see the current HEAD and its recent history.\n" +
Expand Down
2 changes: 1 addition & 1 deletion docs/build.md
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@

1. You do _not_ need to install Gradle to build Bisq. The `gradlew` shell script will install it for you, if necessary.

2. Bisq currently works with JDK 11 only. JDK 12 and above are not supported. You can find out which
2. Bisq currently works with JDK 11 and JDK 15. You can find out which
version you have with:

```sh
Expand Down
8 changes: 4 additions & 4 deletions docs/release-process.md
Original file line number Diff line number Diff line change
Expand Up @@ -69,10 +69,10 @@ Use VirtualBox > 6.1 with following configuration:
#### For every OS

* Install latest security updates
* Install/Upgrade to latest Java 11 SDK
* macOS (brew option): `brew upgrade openjdk@11`
* Ubuntu (brew option): `brew upgrade java11`
* Windows: Download latest version from https://www.oracle.com/java/technologies/javase-jdk11-downloads.html
* Install/Upgrade to latest Java 15 SDK
* macOS (brew option): `brew upgrade zulu15`
* Ubuntu (brew option): `brew upgrade zulu15`
* Windows: Download latest version from https://www.oracle.com/java/technologies/javase/jdk15-archive-downloads.html
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the plan is to start using the Zulu JDK, then the right link here is
https://www.azul.com/downloads/?version=java-15-mts&os=windows&architecture=x86-64-bit&package=jdk

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Windows: Download latest version from https://www.oracle.com/java/technologies/javase/jdk15-archive-downloads.html
* Windows: Download latest version from https://www.azul.com/downloads/?version=java-15-mts&os=windows&architecture=x86-64-bit&package=jdk


#### For Windows

Expand Down