Netty version difference between Azure SDK and Spring Boot

[anumalasri]

We would like to hear from MSFT team on this Netty Version difference between multiple BOMs ..

Spring Boot	Netty Version		Azure Spring	Azure SDK	Azure Netty Version
4.0.0	4.2.7.Final		7.0.0	1.16.3	4.1.130.Final

This results confused log message ( as Azure SDK and Netty are transitive dependencies)

The following Netty versions were found on the classpath and have a mismatch with the versions used by azure-core-http-netty. If your application runs without issue this message can be ignored, otherwise please align the Netty versions used in your application. For more information, see https://aka.ms/azsdk/java/dependency/troubleshoot.

Though we understand Azure SDK is completely different than other Frameworks (Spring Boot, Azure Cloud), is there way to resolve this version difference ?

1. Adhere to latest version along with other frameworks (Spring Boot) (preferred)
2. Is there any possibility to suppress this log?

Being owners of Azure SDK and Azure Cloud, how would like to resolve this ?

[anumalasri]

Spring Boot v4 supports both Jackson3 and Jackson2.

Within Jackson2, the version of 2.18.x from azure and 2.20.x from Spring Bot

Warning Log from c.a.c.i.Utils class : Neither Afterburner nor Blackbird Jackson module loaded. Consider adding one to your classpath for maximum Jackson performance.

[anumalasri]

@samvaity @alzimmermsft Could you please share your comments on this issue ?

[alzimmermsft]

Adhere to latest version along with other frameworks (Spring Boot) (preferred)

At least for Jackson dependencies, the Azure SDKs should be fairly resilient to minor version skew in resolved dependencies, so we're unlikely to upgrade soonish but the logs can be ignored about them. The Netty minor dependency change though was found to have upgrade bugs found in this PR: #47563, and likely won't be upgraded for a while as the root issues are in JDK <-> Netty interactions that could cause crashes in an application.

Since we support multiple versions of Spring (5.x, 6.x, 7.x, etc) at a time we generally try to use the lowest matching versions when possible. Right now, we're in a bit of a difficult spot as there are API breaking changes between the versions they use where if we upgrade we can break 5.x support but by not upgrading we can break 7.x support.

Is there any possibility to suppress this log?

For the Netty log, you should be able to disable logs from com.azure.core.http.netty.implementation.NettyUtility (logs the message in the original issue description, and is the only log message produced by that class: https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/core/azure-core-http-netty/src/main/java/com/azure/core/http/netty/implementation/NettyUtility.java#L98).

For the Jackson log, you should be able to disable logs from com.azure.core.implementation.jackson.JacksonVersion (one of the possible logs about Jackson, https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/core/azure-core/src/main/java/com/azure/core/implementation/jackson/JacksonVersion.java).

@kushagraThapar, for the log messages about Blackbird and Afterburner (https://github.com/Azure/azure-sdk-for-java/blob/main/sdk/cosmos/azure-cosmos/src/main/java/com/azure/cosmos/implementation/Utils.java#L158), we may want to drop the log level down to INFO or VERBOSE as it's an optional import to improve performance.

[jbauerrfid]

In Spring Boot it is possible to select a different version of netty by adding to the pom.xml of the current project:

	<properties>
		<netty.version>4.1.130.Final</netty.version>
	</properties>

But in Azure SDK Microsoft forces a specific version of netty.io on top of us, and they don't support a maven property to override the version.

They ignore the fact that the root of the project dependencies usually comes from Spring Initializer, and then developers add dependencies from Azure SDK where they need functionality not supported by Spring out of the box. Instead they pretend they own Spring Boot and are the source of truth of all dependency versions.

The Azure SDK should get more flexibility to let developers chose which common dependencies should be used. Also the Microsoft Spring Boot starter is no valid alternative as it causes trouble with other items from the original Spring framework.

[anumalasri]

At least for Jackson dependencies, the Azure SDKs should be fairly resilient to minor version skew in resolved dependencies, so we're unlikely to upgrade soonish but the logs can be ignored about them. The Netty minor dependency change though was found to have upgrade bugs found in this PR: #47563, and likely won't be upgraded for a while as the root issues are in JDK <-> Netty interactions that could cause crashes in an application.

Are you saying Azure SDK is NOT compatible with Netty 4.2.x version ?

Since we support multiple versions of Spring (5.x, 6.x, 7.x, etc) at a time we generally try to use the lowest matching versions when possible. Right now, we're in a bit of a difficult spot as there are API breaking changes between the versions they use where if we upgrade we can break 5.x support but by not upgrading we can break 7.x support.

Spring Major versions can bring different versions of dependencies and required to manage compatible versions for Major version. Shall we Azure Spring Cloud to support these versions accordingly?

[alzimmermsft]

Are you saying Azure SDK is NOT compatible with Netty 4.2.x version ?

API usage-wise, everything works fine, but Netty 4.2 has some runtime changes that caused issues when using default settings on Java 25 (a Java 25 bug), this issue goes into more details: netty/netty#16071

Due to that bug, we're holding off on upgrading to Netty 4.2 as we use AsynchronousFileChannel in frequently used code paths and don't want to set any configuration settings for Netty from the SDK. So, we could upgrade, but it would require all SDK users to possibly need to set Netty configurations to work around that bug.