ValidateJavaVersion is expensive

[jeromelaban]

Android application type

.NET Android (net7.0-android, etc.)

Affected platform version

net 7 and later

Description

The task ValidateJavaVersion takes about 23 seconds to run for every project of a solution, even when running on a beefy machine (Standard_L16s_v3 with premium SSDs).

https://github.com/xamarin/xamarin-android/blob/4fffbf686bad5479a8ef7954d7d9d0d68941f034/src/Xamarin.Android.Build.Tasks/Tasks/ValidateJavaVersion.cs#L14

Interestingly, the caching mechanism here does seem to work, but not in a meaningful way:

https://github.com/xamarin/xamarin-android/blob/4fffbf686bad5479a8ef7954d7d9d0d68941f034/src/Xamarin.Android.Build.Tasks/Tasks/ValidateJavaVersion.cs#L104

Steps to Reproduce

Build any android library and observe the task takes a long time to run. In a large solution, this accounts for about 4 minutes of build time.

Did you find any workaround?

None at this time.

Relevant log output

No response

[dellis1972]

out of curisity how long does java -version take to run on the command line?
also what output does it produce for your sdk? (I see you are using a custom java sdk).

[microsoft-github-policy-service]

Hi @jeromelaban. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[jeromelaban]

So running the commands directly give a 7.4s for java.exe and 3.8s for javac.exe. Do you get similar values on your end?

About the Java SDK, we're using is the one by default on azure devops hosted agents, but maybe we've been using the wrong one for a while... which one's the most appropriate in that context?

[dellis1972]

so on my mac I get the following

 time java -version
openjdk version "17.0.8" 2023-07-18 LTS
OpenJDK Runtime Environment Microsoft-8035246 (build 17.0.8+7-LTS)
OpenJDK 64-Bit Server VM Microsoft-8035246 (build 17.0.8+7-LTS, mixed mode, sharing)
java -version  0.04s user 0.03s system 81% cpu 0.094 total

So that is really odd its taking so long. I'll have to try on a windows box somewhere and see what I see.

[jonathanpeppers]

One thing to note is that we cache the results of these calls with an AppDomain lifetime with RegisterTaskObject. So you'd see this on the first build per MSBuild node unless the Java SDK path changes.

We do call both javac -version and java -version, maybe we could drop one of those?

[jonathanpeppers]

@jeromelaban can you tell if the Java SDK path is changing between calls? Maybe this invalidates the cache for all of them?