[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.

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

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

[build] Use Microsoft OpenJDK 21.0.5 #9651

Are you sure you want to change the base?

[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