[build] Use Microsoft OpenJDK 21.0.5 #9651

jonpryor · 2025-01-06T19:26:13Z

Context: 298da11

Does It Build™?

We have customers asking if they can use JDK 21.
@jonpryor has no idea!

Let's find out!

Update Step_InstallAdoptOpenJDK.MacOS.cs to run
xattr -d -r com.apple.quarantine $HOME/android-toolchain/jdk-21. This is because tar xzf will apply the "quarantined" attribute to extracted files, which prevents execution of e.g. javac:

% $HOME/android-toolchain/jdk-21/bin/javac
zsh: operation not permitted: ./jdk-21/bin/javac

Removing the com.apple.quarantine attribute fixes this.

@jonpryor

Context: 298da11 Does It Build™? We have customers asking if they can use JDK 21. @jonpryor has no idea! Let's find out! Update `Step_InstallAdoptOpenJDK.MacOS.cs` to run `xattr -d -r com.apple.quarantine $HOME/android-toolchain/jdk-21`. This is because `tar xzf` will apply the "quarantined" attribute to extracted files, which prevents execution of e.g. `javac`: % $HOME/android-toolchain/jdk-21/bin/javac zsh: operation not permitted: ./jdk-21/bin/javac Removing the `com.apple.quarantine` attribute fixes this.

jonpryor · 2025-01-06T19:29:39Z

/azp run

azure-pipelines · 2025-01-06T19:30:10Z

Azure Pipelines successfully started running 1 pipeline(s).

@jonpryor

Context: #9651 Recent versions of macOS, Safari, and **tar**(1) [^0] interact such that if you manually download a tarball and extract it, *all the extracted files* contain the `com.apple.quarantine` extended attribute. This is a security feature, but it also means that the provisioned JDK *cannot be used*: % $HOME/android-toolchain/jdk-21/bin/javac zsh: operation not permitted: ./jdk-21/bin/javac Which in turn means if you do something "reasonable" like download Microsoft OpenJDK and place it into `$HOME/android-archives` -- so that `xaprepare` doesn't need to download it *again* -- then the provisioned JDK will be *unusable*. Which makes @jonpryor sad. Update `Step_InstallAdoptOpenJDK.MacOS.cs` to run `xattr -d -r com.apple.quarantine $HOME/android-toolchain/jdk-21`. This will *delete* the offending extended attribute, allowing e.g. `javac` to run without error. [^0]: Which versions? ¯\_(ツ)_/¯

@jonpryor

Context: #9651 Recent versions of macOS, Safari, and **tar**(1) [^0] interact such that if you manually download a tarball and extract it, *all the extracted files* contain the `com.apple.quarantine` extended attribute. This is a security feature, but it also means that the provisioned JDK *cannot be used*: % $HOME/android-toolchain/jdk-21/bin/javac zsh: operation not permitted: ./jdk-21/bin/javac Which in turn means if you do something "reasonable" like download Microsoft OpenJDK and place it into `$HOME/android-archives` -- so that `xaprepare` doesn't need to download it *again* -- then the provisioned JDK will be *unusable*. Which makes @jonpryor sad. Update `Step_InstallAdoptOpenJDK.MacOS.cs` to run `xattr -d -r com.apple.quarantine $HOME/android-toolchain/jdk-21`. This will *delete* the offending extended attribute, allowing e.g. `javac` to run without error. [^0]: Which versions? ¯\\_(ツ)_/¯

Context: 5bb0d24 Context: 4273e5c Context: 0355acf Context: dotnet/android#9651 Does dotnet/android build with JDK-21? We don't know! But in order to answer that question, dotnet/java-interop needs to be able to build under JDK-21; a'la 5bb0d24: 1. [Install JDK-21][0] 2. Run `dotnet build -t:Prepare`, overriding `$(JdksRoot)`: dotnet build -t:Prepare Java.Interop.sln -p:JdksRoot=/Library/Java/JavaVirtualMachines/microsoft-21.jdk/Contents/Home 3. Build: `dotnet build` Unfortunately, this *fails* for three reasons: 1. `class-parse` crashes when processing `java.base.jmod`. 2. `src/Java.Base` needs updates to bind JDK-21's `java.base.jmod`. 3. On Linux and Windows, Gradle 8.1 and JDK-21 don't mix. ~~ class-parse ~~ This only impacts Debug builds of dotnet/java-interop, but: % dotnet "bin/Debug-net8.0/class-parse.dll" \ "$HOME/android-toolchain/jdk-21/jmods/java.base.jmod" \ "-o=obj/Debug-net8.0//mcw/api.xml" … Process terminated. Assertion failed. Unexpected number of method parameters in `Ljdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter$Instantiation;.get(Ljava/lang/Object;)Ljava/lang/Object;`: expected 1, got 0 at Xamarin.Android.Tools.Bytecode.MethodInfo.UpdateParametersFromMethodParametersAttribute(ParameterInfo[] parameters) in …/src/Xamarin.Android.Tools.Bytecode/Methods.cs:line 308 … The assertion? var pinfo = methodParams.ParameterInfo; int startIndex = 0; while (startIndex < pinfo.Count && pinfo [startIndex].AccessFlags.HasFlag (.Synthetic)) startIndex++; Debug.Assert (parameters.Length == pinfo.Count - startIndex, …); This is part of 4273e5c and 0355acf, attempting to "skip over" the constructor parameters which non-static inner classes have which contain the outer class instance: // Java class Outer { /* non-static */ class Inner { public Inner () { … } } } At the ABI boundary, the `Outer.Inner` constructor is actually: /* partial */ class Outer { /* partial */ class Inner { public Inner (Outer outer) { … } } } and we need to skip over the first parameter. Which brings us to `jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter.Instantiation.get()`: % mkdir _x % unzip $HOME/android-toolchain/jdk-21/jmods/java.base.jmod -d _x % dotnet bin/Debug-net8.0/class-parse.dll --dump \ _x/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter\$Instantiation.class … 8: get (Ljava/lang/Object;)Ljava/lang/Object; Public, Bridge, Synthetic Code(6, Unknown[LineNumberTable](6), LocalVariableTableAttribute(LocalVariableTableEntry(Name='this', Descriptor='Ljdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter$Instantiation;', StartPC=0, Index=0))) MethodParametersAttribute(MethodParameterInfo(Name='', AccessFlags=Final, Synthetic)) The parameter for `JSRInlinerAdapter.Instantiation.get(Object)` is `Synthetic`, causing us to skip over it, which is why we have a parameter mismatch. The thing is, this parameter *shouldn't* be skipped; the skipping is intended for *constructor* parameters! Update the code so that the loop only occurs for constructors. This allows `class-parse` to *not assert*, allowing `src/Java.Base` to build. ~~ Gradle ~~ Via dotnet/android#9651, `gradle` fails when building `tools/java-source-utils`, but only on Linux and Windows: "/mnt/vss/_work/1/s/xamarin-android/external/Java.Interop/build-tools/gradle/gradlew" -d --stacktrace --no-daemon -PjavaSourceVer=11 -PjavaTargetVer=11 jar … [org.gradle.internal.buildevents.BuildExceptionReporter] [org.gradle.internal.buildevents.BuildExceptionReporter] FAILURE: Build failed with an exception. [org.gradle.internal.buildevents.BuildExceptionReporter] [org.gradle.internal.buildevents.BuildExceptionReporter] * What went wrong: [org.gradle.internal.buildevents.BuildExceptionReporter] Could not open settings generic class cache for settings file '/mnt/vss/_work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/settings.gradle' (/home/cloudtest/.gradle/caches/8.1.1/scripts/aiw0k2bokig45bv5yvkog3o3j). [org.gradle.internal.buildevents.BuildExceptionReporter] > BUG! exception in phase 'semantic analysis' in source unit '_BuildScript_' Unsupported class file major version 65 [org.gradle.internal.buildevents.BuildExceptionReporter] [org.gradle.internal.buildevents.BuildExceptionReporter] * Try: [org.gradle.internal.buildevents.BuildExceptionReporter] > Run with --scan to get full insights. [org.gradle.internal.buildevents.BuildExceptionReporter] [org.gradle.internal.buildevents.BuildExceptionReporter] * Exception is: [org.gradle.internal.buildevents.BuildExceptionReporter] org.gradle.cache.CacheOpenException: Could not open settings generic class cache for settings file '/mnt/vss/_work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/settings.gradle' (/home/cloudtest/.gradle/caches/8.1.1/scripts/aiw0k2bokig45bv5yvkog3o3j). [org.gradle.internal.buildevents.BuildExceptionReporter] at org.gradle.cache.internal.DefaultPersistentDirectoryStore.open(DefaultPersistentDirectoryStore.java:91) [org.gradle.internal.buildevents.BuildExceptionReporter] … [org.gradle.internal.buildevents.BuildExceptionReporter] Caused by: BUG! exception in phase 'semantic analysis' in source unit '_BuildScript_' Unsupported class file major version 65 [org.gradle.internal.buildevents.BuildExceptionReporter] at org.gradle.groovy.scripts.internal.DefaultScriptCompilationHandler.compileScript(DefaultScriptCompilationHandler.java:147) [org.gradle.internal.buildevents.BuildExceptionReporter] … [org.gradle.internal.buildevents.BuildExceptionReporter] Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 65 [org.gradle.internal.buildevents.BuildExceptionReporter] at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:199) 🤔 As per the [Gradle Compatibility Matrix][1], Java 21 requires Gradle 8.5 or later. (No idea why this works on macOS…) Bump to Gradle 8.12, whic is the current latest stable version. ~~ TODO ~~ While dotnet/java-interop now *builds* with JDK-21, unit tests don't fully pass. In particular, `tests/Xamarin.Android.Tools.Bytecode-Tests` will need to be updated because `javac` output has changed. (Again.) [0]: https://learn.microsoft.com/en-us/java/openjdk/download#openjdk-21 [1]: https://docs.gradle.org/8.12/userguide/compatibility.html

Try dotnet/java-interop#1287, which contains a Gradle bump, which is probably needed because previously Linux & Windows failed to build because Gradle 8.1 and JDK-21 don't mix. Update `$(LatestSupportedJavaVersion)` to 21.0.99 so that our unit tests will actually *try* to do something under JDK-21, instead of insta-failing with an XA0030 error: > error XA0030: Building with JDK version `21.0.5` is not supported. > Please install JDK version `17.0`. See https://aka.ms/xamarin/jdk9-errors Doh. Update to Gradle 8.12, for harmony with dotnet/java-interop#1287.

jonpryor · 2025-01-07T20:20:52Z

/azp run

azure-pipelines · 2025-01-07T20:21:24Z

Azure Pipelines successfully started running 1 pipeline(s).

@jonpryor

Context: #9651 Recent versions of macOS, Safari, and **tar**(1) [^0] interact such that if you manually download a tarball and extract it, *all the extracted files* contain the `com.apple.quarantine` extended attribute. This is a security feature, but it also means that the provisioned JDK *cannot be used*: % $HOME/android-toolchain/jdk-21/bin/javac zsh: operation not permitted: ./jdk-21/bin/javac Which in turn means if you do something "reasonable" like download Microsoft OpenJDK and place it into `$HOME/android-archives` -- so that `xaprepare` doesn't need to download it *again* -- then the provisioned JDK will be *unusable*. Which makes @jonpryor sad. Update `Step_InstallAdoptOpenJDK.MacOS.cs` to run `xattr -d -r com.apple.quarantine $HOME/android-toolchain/jdk-21`. This will *delete* the offending extended attribute, allowing e.g. `javac` to run without error. [^0]: Which versions? ¯\\_(ツ)_/¯

Context: 5bb0d24 Context: 4273e5c Context: 0355acf Context: dotnet/android#9651 Does dotnet/android build with JDK-21? We don't know! But in order to answer that question, dotnet/java-interop needs to be able to build under JDK-21; a'la 5bb0d24: 1. [Install JDK-21][0] 2. Run `dotnet build -t:Prepare`, overriding `$(JdksRoot)` to refer to the JDK-21 installation directory: dotnet build -t:Prepare Java.Interop.sln -p:JdksRoot=/Library/Java/JavaVirtualMachines/microsoft-21.jdk/Contents/Home 3. Build: `dotnet build` Unfortunately, this *fails* for three reasons: 1. `class-parse` crashes when processing JDK-21's `java.base.jmod`. 2. `src/Java.Base` needs updates to bind JDK-21's `java.base.jmod`. 3. On Linux and Windows, Gradle 8.1 and JDK-21 don't mix. ~~ class-parse ~~ This only impacts Debug builds of dotnet/java-interop, but: % dotnet "bin/Debug-net8.0/class-parse.dll" \ "$HOME/android-toolchain/jdk-21/jmods/java.base.jmod" \ "-o=obj/Debug-net8.0//mcw/api.xml" … Process terminated. Assertion failed. Unexpected number of method parameters in `Ljdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter$Instantiation;.get(Ljava/lang/Object;)Ljava/lang/Object;`: expected 1, got 0 at Xamarin.Android.Tools.Bytecode.MethodInfo.UpdateParametersFromMethodParametersAttribute(ParameterInfo[] parameters) in …/src/Xamarin.Android.Tools.Bytecode/Methods.cs:line 308 … The assertion? var pinfo = methodParams.ParameterInfo; int startIndex = 0; while (startIndex < pinfo.Count && pinfo [startIndex].AccessFlags.HasFlag (.Synthetic)) startIndex++; Debug.Assert (parameters.Length == pinfo.Count - startIndex, …); This is part of 4273e5c and 0355acf, attempting to "skip over" the constructor parameters which non-static inner classes have which contain the outer class instance: // Java class Outer { /* non-static */ class Inner { public Inner () { … } } } At the ABI boundary, the `Outer.Inner` constructor is actually: // "Equivalent" Java for JNI purposes /* partial */ class Outer { /* partial */ class Inner { public Inner (Outer outer) { … } // note added constructor parameter } } and we need to skip over the first parameter. Which brings us to `jdk.internal.org.objectweb.asm.commons.JSRInlinerAdapter.Instantiation.get()`: % mkdir _x % unzip $HOME/android-toolchain/jdk-21/jmods/java.base.jmod -d _x % dotnet bin/Debug-net8.0/class-parse.dll --dump \ _x/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter\$Instantiation.class … 8: get (Ljava/lang/Object;)Ljava/lang/Object; Public, Bridge, Synthetic Code(6, Unknown[LineNumberTable](6), LocalVariableTableAttribute(LocalVariableTableEntry(Name='this', Descriptor='Ljdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter$Instantiation;', StartPC=0, Index=0))) MethodParametersAttribute(MethodParameterInfo(Name='', AccessFlags=Final, Synthetic)) The parameter for `JSRInlinerAdapter.Instantiation.get(Object)` is `Synthetic`, causing us to skip over it, which is why we have a parameter mismatch. The thing is, this parameter *shouldn't* be skipped; the skipping is intended for *constructor* parameters! Update the code so that the loop only occurs for constructors. This allows `class-parse` to *not assert*, allowing `src/Java.Base` to build. ~~ Gradle ~~ Via dotnet/android#9651, `gradle` fails when building `tools/java-source-utils`, but only on Linux and Windows: "/mnt/vss/_work/1/s/xamarin-android/external/Java.Interop/build-tools/gradle/gradlew" -d --stacktrace --no-daemon -PjavaSourceVer=11 -PjavaTargetVer=11 jar … [org.gradle.internal.buildevents.BuildExceptionReporter] [org.gradle.internal.buildevents.BuildExceptionReporter] FAILURE: Build failed with an exception. [org.gradle.internal.buildevents.BuildExceptionReporter] [org.gradle.internal.buildevents.BuildExceptionReporter] * What went wrong: [org.gradle.internal.buildevents.BuildExceptionReporter] Could not open settings generic class cache for settings file '/mnt/vss/_work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/settings.gradle' (/home/cloudtest/.gradle/caches/8.1.1/scripts/aiw0k2bokig45bv5yvkog3o3j). [org.gradle.internal.buildevents.BuildExceptionReporter] > BUG! exception in phase 'semantic analysis' in source unit '_BuildScript_' Unsupported class file major version 65 [org.gradle.internal.buildevents.BuildExceptionReporter] [org.gradle.internal.buildevents.BuildExceptionReporter] * Try: [org.gradle.internal.buildevents.BuildExceptionReporter] > Run with --scan to get full insights. [org.gradle.internal.buildevents.BuildExceptionReporter] [org.gradle.internal.buildevents.BuildExceptionReporter] * Exception is: [org.gradle.internal.buildevents.BuildExceptionReporter] org.gradle.cache.CacheOpenException: Could not open settings generic class cache for settings file '/mnt/vss/_work/1/s/xamarin-android/external/Java.Interop/tools/java-source-utils/settings.gradle' (/home/cloudtest/.gradle/caches/8.1.1/scripts/aiw0k2bokig45bv5yvkog3o3j). [org.gradle.internal.buildevents.BuildExceptionReporter] at org.gradle.cache.internal.DefaultPersistentDirectoryStore.open(DefaultPersistentDirectoryStore.java:91) [org.gradle.internal.buildevents.BuildExceptionReporter] … [org.gradle.internal.buildevents.BuildExceptionReporter] Caused by: BUG! exception in phase 'semantic analysis' in source unit '_BuildScript_' Unsupported class file major version 65 [org.gradle.internal.buildevents.BuildExceptionReporter] at org.gradle.groovy.scripts.internal.DefaultScriptCompilationHandler.compileScript(DefaultScriptCompilationHandler.java:147) [org.gradle.internal.buildevents.BuildExceptionReporter] … [org.gradle.internal.buildevents.BuildExceptionReporter] Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 65 [org.gradle.internal.buildevents.BuildExceptionReporter] at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:199) 🤔 As per the [Gradle Compatibility Matrix][1], Java 21 requires Gradle 8.5 or later. (No idea why this works on macOS…) Bump to Gradle 8.12, which is the current latest stable version. ~~ TODO ~~ While dotnet/java-interop now *builds* with JDK-21, unit tests don't fully pass. In particular, `tests/Xamarin.Android.Tools.Bytecode-Tests` will need to be updated because `javac` output has changed. (Again.) [0]: https://learn.microsoft.com/en-us/java/openjdk/download#openjdk-21 [1]: https://docs.gradle.org/8.12/userguide/compatibility.html

Otherwise we're trying to replace the JDK-17 install with our own JDK-21, which fails horrifically.

jonpryor · 2025-01-08T21:34:22Z

/azp run

azure-pipelines · 2025-01-08T21:34:29Z

Pull request contains merge conflicts.

…k-21-work-p

jonpryor · 2025-01-09T00:09:05Z

/azp run

azure-pipelines · 2025-01-09T00:09:34Z

Azure Pipelines successfully started running 1 pipeline(s).

jonpryor · 2025-01-09T02:33:05Z

Tests are now actually run. So how are we faring?

CheckSignApk(False,True) is failing because it emitted a warning:

JAVAC : warning : [options] system modules path not set in conjunction with -source 17

Which is also why DotNetBuild(…), SuccessfulAndroidXApp, SupportedOSPlatformVersion("35.0",False), and other tests have failed. (It might be the cause for all tests failures?)

jonpryor · 2025-01-09T02:40:47Z

So what is our "offending" javac invocation?

javac response file contents: C:\Users\cloudtest\AppData\Local\Temp\tmpery0pn.tmp
-d "obj\Release\android\bin\classes\"
-classpath "D:\a\_work\1\s\bin\Release\dotnet\packs\Microsoft.Android.Sdk.Windows\35.99.0-ci.pr.gh9651.94\tools\\java_runtime_net6.jar;D:\a\_work\1\s\bin\Release\dotnet\packs\Microsoft.NETCore.App.Runtime.Mono.android-arm\9.0.0-rtm.24510.3\runtimes\android-arm\native\libSystem.Security.Cryptography.Native.Android.jar;C:\Android\android-sdk\platforms\android-35\android.jar"
-encoding UTF8
"obj\Release\android\src\mono\MonoPackageManager_Resources.java"
"obj\Release\android\src\mono\MonoRuntimeProvider.java"
"obj\Release\android\src\mono\TypeManager.java"
"obj\Release\android\src\android\runtime\JavaProxyThrowable.java"
"obj\Release\android\src\com\xamarin\checksignapk\MainActivity.java"
"obj\Release\android\src\com\xamarin\checksignapk\R.java"
"obj\Release\android\src\mono\android\app\ApplicationRegistration.java"
"obj\Release\android\src\mono\android\runtime\InputStreamAdapter.java"
"obj\Release\android\src\mono\android\runtime\OutputStreamAdapter.java"
"obj\Release\android\src\mono\android\view\View_OnClickListenerImplementor.java"
"obj\Release\android\src\mono\java\lang\RunnableImplementor.java"
C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\21.0.5-11.0\x64\bin\javac.exe -J-Dfile.encoding=UTF8 "@C:\Users\cloudtest\AppData\Local\Temp\tmpery0pn.tmp" -target 17 -source 17

jonpryor · 2025-01-09T02:53:14Z

Fortunately this is actually easy to repro: javac hello-world.java -source 17 -target 17 emits the warning.

I thus turn to the man page:

% man $HOME/android-toolchain/jdk-21/man/man1/javac.1

Which has some interesting things in there:

       --release release
              Compiles source code according to the rules of the Java
              programming language for the specified Java SE release,
              generating class files which target that release.  Source code
              is compiled against the combined Java SE and JDK API for the
              specified release.

              The supported values of release are the current Java SE release
              and a limited number of previous releases, detailed in the
              command-line help.

              For the current release, the Java SE API consists of the java.*,
              javax.*, and org.* packages that are exported by the Java SE
              modules in the release; the JDK API consists of the com.* and
              jdk.* packages that are exported by the JDK modules in the
              release, plus the javax.* packages that are exported by
              standard, but non-Java SE, modules in the release.

              For previous releases, the Java SE API and the JDK API are as
              defined in that release.

              Note: When using --release, you cannot also use the
              --source/-source or --target/-target options.

And indeed, javac hello-world.java --release 17 does not emit a warning. Nice!

Unfortunately, the docs for -source and -target aren't as helpful:

       --source release or -source release
              Compiles source code according to the rules of the Java
              programming language for the specified Java SE release.  The
              supported values of release are the current Java SE release and
              a limited number of previous releases, detailed in the command-
              line help.

              If the option is not specified, the default is to compile source
              code according to the rules of the Java programming language for
              the current Java SE release.
…
       --target release or -target release
              Generates class files suitable for the specified Java SE
              release.  The supported values of release are the current Java
              SE release and a limited number of previous releases, detailed
              in the command-line help.

              Note: The target release must be equal to or higher than the
              source release.  (See --source.)

No mention of "modules" or setting a "system modules path".

…after remembering that -foo tells search engines to not include "foo" -- doh! -- I now find this interesting and relevant stackoverflow answer:

(recommended) Replace -source and -target by --release. This option implicitly includes a check against the API version of the targeted JRE/JDK! Therefor the message goes away as well.

Add addtionally the --system option to javac pointing to a JDK of the same version as --source. Setting that parameter allows javac to take the API into account as well. It is roughly a replacement for -bootclasspath with the difference that it doesn't point to a "rt.jar", but to the root directory, like JAVA_HOME would do. Think of it as a "old JAVA_HOME" option.

jonpryor · 2025-01-09T02:56:51Z

Fortunately JDK-17 supports javac --release, so I don't need a version check on javac…

Hopefully fixes Hopefully fies the warning: > JAVAC : warning : [options] system modules path not set in conjunction with -source 17

jonpryor · 2025-01-09T03:03:19Z

/azp run

azure-pipelines · 2025-01-09T03:03:49Z

Azure Pipelines successfully started running 1 pipeline(s).

jonpryor · 2025-01-09T14:13:46Z

Using javac --release fixed many of the test failures.

But not all. 17 are failing.

MauiTargetFramework("net8.0","android",34) fails because it's trying to build net8.0-android34, which fails with XA0030 because .NET 8's $(LatestSupportedJavaVersion) rejects JDK-21.

DotNetPack("net8.0","android",34) is the same. As is ApplicationRunsWithDebuggerAndBreaks(True,False,null,"apk",False), and all the others.

Context: #9651 PR #9651 demonstrated that it was fairly straightforward to use JDK-21 on CI. We don't want to fully bump to JDK-21, because we still support building with JDK-17, so we *at minimum* need to run tests on both JDK-17 and JDK-21. As a "minimal introductory step", add support for JDK-21: * Update to Gradle 8.12, for harmony with dotnet/java-interop. * Update the `<Javac/>` task to use `javac --release N` when using JDK-17 and later. JDK-11 doesn't support `javac --release`. (Why care about JDK-11? Because .NET 8 still supports it, and this will make future cherry-picking easier.) * Set `$(LatestSupportedJavaVersion)`=21.0.99, which removes the XA0030 error which would result from using JDK-21. * Update `tools/workload-dependencies` to use `$(LatestSupportedJavaVersion)` property, instead of always using `$(JavaSdkVersion)+1`.

* [build] Support JDK-21 Context: #9651 PR #9651 demonstrated that it was fairly straightforward to use JDK-21 on CI. We don't want to fully bump to JDK-21, because we still support building with JDK-17, so we *at minimum* need to run tests on both JDK-17 and JDK-21. As a "minimal introductory step", add support for JDK-21: * Update to Gradle 8.12, for harmony with dotnet/java-interop. * Update the `<Javac/>` task to use `javac --release N` when using JDK-17 and later. JDK-11 doesn't support `javac --release`. (Why care about JDK-11? Because .NET 8 still supports it, and this will make future cherry-picking easier.) * Set `$(LatestSupportedJavaVersion)`=21.0.99, which removes the XA0030 error which would result from using JDK-21. * Update `tools/workload-dependencies` to use `$(LatestSupportedJavaVersion)` property, instead of always using `$(JavaSdkVersion)+1`. * Address comments.

Context: #9651 Context: 14a6bfb Updates the macOS, Windows, and Linux build stages to install and build with Microsoft OpenJDK 21.0.5. The macOS MSBuild tests and nightly APK tests have also been updated to use JDK 21, while all other test jobs should continue to use JDK 17.

pjcollins · 2025-01-16T16:43:33Z

I'm going to close this in favor of 14a6bfb and #9683, and we can look to expand JDK 21 usage further if/when we choose to install it by default for customers.

Context: #9651 Context: 14a6bfb Context: df68c20 As of 14a6bfb, main/.NET 10 supports both JDK 17 and 21. The default version that VS and the `InstallAndroidDependencies` target will install is currently JDK 17, though we may want to upgrade this to JDK 21 as we move further into the .NET 10 cycle. In order to increase our JDK test coverage across versions, the macOS, Windows, and Linux build stages have been updated to install and build with Microsoft OpenJDK 21.0.5. The nightly test jobs have also been updated to use JDK 21, while all other test jobs will continue to use JDK 17. JDK 11 support was removed in df68c20, though customers should be able to add: `<MinimumSupportedJavaVersion>11.0</MinimumSupportedJavaVersion>` to their project files to use it. Some test coverage for this exists in [ValidateJavaVersionTests][0], but this is not fully tested end to end. [0]: https://github.com/dotnet/android/blob/766ac338446f99129168dc02a16669882f6bd34e/src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/Tasks/ValidateJavaVersionTests.cs

jonpryor mentioned this pull request Jan 6, 2025

[build+macOS] Remove quarantine from OpenJDK installations #9652

Merged

davidbritch mentioned this pull request Jan 7, 2025

New VSCode installation and first app docs dotnet/docs-maui#2707

Merged

jonpryor mentioned this pull request Jan 7, 2025

[build] Add support for JDK 21 dotnet/java-interop#1287

Merged

jonpryor added 2 commits January 8, 2025 15:33

Use $(LatestSupportedJavaVersion) for max supported JDK version.

0a8ae17

Use $(JAVA_HOME_21_X64)

2e5446d

Otherwise we're trying to replace the JDK-17 install with our own JDK-21, which fails horrifically.

Merge remote-tracking branch 'origin/main' into dev/jonp/jonp-does-jd…

f0a62d7

…k-21-work-p

Use javac --release N, not javac -source N -target N

26be552

Hopefully fixes Hopefully fies the warning: > JAVAC : warning : [options] system modules path not set in conjunction with -source 17

jonpryor mentioned this pull request Jan 10, 2025

[build] Support JDK-21 #9672

Merged

pjcollins mentioned this pull request Jan 14, 2025

[build] Build with Microsoft OpenJDK 21.0.5 #9683

Merged

pjcollins closed this Jan 16, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[build] Use Microsoft OpenJDK 21.0.5 #9651

[build] Use Microsoft OpenJDK 21.0.5 #9651

jonpryor commented Jan 6, 2025

jonpryor commented Jan 6, 2025

azure-pipelines bot commented Jan 6, 2025

jonpryor commented Jan 7, 2025

azure-pipelines bot commented Jan 7, 2025

jonpryor commented Jan 8, 2025

azure-pipelines bot commented Jan 8, 2025

jonpryor commented Jan 9, 2025

azure-pipelines bot commented Jan 9, 2025

jonpryor commented Jan 9, 2025

jonpryor commented Jan 9, 2025

jonpryor commented Jan 9, 2025

jonpryor commented Jan 9, 2025

jonpryor commented Jan 9, 2025

azure-pipelines bot commented Jan 9, 2025

jonpryor commented Jan 9, 2025

pjcollins commented Jan 16, 2025 •

edited

Loading

[build] Use Microsoft OpenJDK 21.0.5 #9651

[build] Use Microsoft OpenJDK 21.0.5 #9651

Conversation

jonpryor commented Jan 6, 2025

jonpryor commented Jan 6, 2025

azure-pipelines bot commented Jan 6, 2025

jonpryor commented Jan 7, 2025

azure-pipelines bot commented Jan 7, 2025

jonpryor commented Jan 8, 2025

azure-pipelines bot commented Jan 8, 2025

jonpryor commented Jan 9, 2025

azure-pipelines bot commented Jan 9, 2025

jonpryor commented Jan 9, 2025

jonpryor commented Jan 9, 2025

jonpryor commented Jan 9, 2025

jonpryor commented Jan 9, 2025

jonpryor commented Jan 9, 2025

azure-pipelines bot commented Jan 9, 2025

jonpryor commented Jan 9, 2025

pjcollins commented Jan 16, 2025 • edited Loading

pjcollins commented Jan 16, 2025 •

edited

Loading