Commits on Jan 22, 2024

1. [Xamarin.Android.Build.Tasks] parse JDK release file directly …

   Fixes: dotnet#8369
   
   During Android project builds, the `<ValidateJavaVersion/>` MSBuild task
   currently shells out to `java -version` and `javac -version` to
   determine if we have a *valid* & usable JDK.
   
   Unfortunately, some customer logs have reported build times that are
   completely bananas:
   
       Task ValidateJavaVersion 23.469s
       ...
       Top 10 most expensive tasks
       ...
       ValidateJavaVersion = 3:46.740, 35 calls
   
   `java -version` and/or `javac -version` must be quite slow! Reading the
   source for OpenJDK, it appears that `java -version` actually starts a
   JVM to call a single method:
   
   * https://github.com/openjdk/jdk/blob/df370d725e5ae55a05479e8375bf665233ac3e44/src/java.base/share/native/libjli/java.c#L1895-L1913
   * https://github.com/openjdk/jdk/blob/c9cacfb25d1f15c879c961d2965a63c9fe4d9fa7/src/java.base/share/classes/java/lang/VersionProps.java.template#L191-L233
   
   That could explain the slowness?
   
   To improve this, let's just parse the file:
   
   * C:\Program Files\Microsoft\jdk-11.0.19.7-hotspot\release
   
   With contents:
   
       IMPLEMENTOR="Microsoft"
       IMPLEMENTOR_VERSION="Microsoft-7621296"
       JAVA_VERSION="11.0.19"
       JAVA_VERSION_DATE="2023-04-18"
       LIBC="default"
       MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.crypto.mscapi jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.internal.le jdk.internal.opt jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.ldap jdk.naming.rmi jdk.net jdk.pack jdk.rmic jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"
       OS_ARCH="x86_64"
       OS_NAME="Windows"
       SOURCE=".:git:6171c19d2c18"
   
   We can just call `StreamReader.ReadLine()` until `JAVA_VERSION="` is
   found.
   
   I kept the existing logic in place, with an escape hatch if it were ever
   needed. After a few .NET 9 previews, we could consider removing old
   logic entirely?
   
   This logic is considerably faster, because we no longer launch a JVM!
   
   * Before: Task ValidateJavaVersion 377ms
   * After: Task ValidateJavaVersion 2ms
   
   Where you can test the "Before" logic by passing
   `-p:_AndroidUseJavaExeVersion=true`.
   
   I assume the customer's log from before (35 calls) would be around 70ms
   give or take instead of 3 hours and 46 minutes? Even if this estimation
   was 10x worse, it would still be a huge improvement! :eyes:

   

   jonathanpeppers committed Jan 22, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for d184d36
   • Browse repository at this point

   Copy the full SHA

   d184d36 View commit details

   Browse the repository at this point in the history