Azure DevOps hosted build "java" demanded capability not present

Hard-coded Azure DevOps build agent demand capability for “java” doesn’t exist on hosted agents or where using OpenJDK, preventing build from starting. Given that Oracle is now charging license fees for their Java, nobody want to install that anymore (Microsoft does not either). OpenJDK is referenced in the JAVA_HOME capability instead. Suggest changing forced demand from “java” to “JAVA_HOME”.

All you need to do is approve this Pull Request:

1 Like

So, I just realized that Linux build servers typically list the ‘java’ capability instead of ‘JAVA_HOME’ which is typical for Windows build servers. I wonder if there is a way to have an “OR” condition on demand? Maybe its better to just remove the demand all together?

@Julien_HENRY @Gregoire_Aubert I see that this commit is still outstanding for the code base. Is there a plan to review this and accept it? This issue is becoming a headache for us due to teams discovering this issue with us removing Oracle Java and replacing it with OpenJDK.

Secondly, does Java need to be on the Build Server itself for the task? My SonarQube installation is on a totally different server from the Build Server. Is the Java install required for SonarQube itself or for the task? If for SonarQube only, then do we need a Demand for Azure DevOps at all since my SonarQube is not even on the Build Server. Trying to understand the what is needed for the SonarQube task to successfully work on the Build Server.

Thanks
Anthony

Hi,

Java demand is needed because the ‘Run Analysis task’ launches a java scanner internally, so no matter which type of host OS the pipeline is executed on, it needs that requirement.

Mickaël

To address the question about demands, I don’t think it’s possible to specify conditional demands for an Azure DevOps extension.

The underlying problem seems to be a bug in the Microsoft agent capability detection code which doesn’t handle locating non-Oracle Java installations correctly (e.g. the Windows agent code looks for registry entries that don’t exist for non-Oracle Java installations).

The simplest workaround is to set a “java” environment variable when creating the build agent.