It is a matter of opinion. getNetworkTimeout, as it is documented returns 0 if there is no network timeout (if it is infinite). What is the reason not to suport it if its support is trivial .

OTOH, supporting for setNetworkTimeout is also trivial via socket option (one just needs to make sure to close connections once this timeout fires)

One could argue that it is not a matter of opinion. The JavaDoc for setNetworkConnection() in the throws section says it throws:

While the JavaDoc for getNetworkTimeout() *does* say it returns 0 when "there is no limit", it also declares:

Clearly, returning 0 from a method is trivial, so any driver can trivially "support this method", so what then is the point of declaring that it can throw SQLFeatureNotSupportedException? It seems clear that if a driver does not support the concept of network timeout in general, it is obligated to throw this exception.

In the experience of HikariCP, as a connection pool under which users have placed many many JDBC drivers, this is the first time we have encountered this behavior.

I think it is reasonable for a user calling getNetworkTimeout(), and receiving a valid response, to assume that they can call setNetworkTimeout() without an exception.

I think you are trying to interpret too much of what JDBC is saying . It is saying 0 means no limit.
Every new method in JDBC 4.0 can throw FeatureNotSupporteException, so it does not mean anything. Specifically it does not mean "if one of any get/set methods throws SQLFeatureNotSupportedException, the other one must do the same". That assumption is wrong in my opinion

I can imagine reasons why getter can work and setter would fail. Imagine a driver that supports timeout, but only at creation time (e.g via "&timeout=1" in connection URL). This timeout cannot be changed at runtime. What should "set" do? fail with SQLFeatureNotSupportedException, IMO. What would "get" do ? return timeout which was set on creation.

I can understand your reasoning, and I cannot in earnesty say you are wrong. We at HikariCP in fact "coded around" the issue, so it is no longer causing failures for our users. But given that MariaDB does not support setting a timeout via URL at creation time, or support configuring a network timeout in any way, we would argue that the "more correct" thing would be to throw the exception. Again, that is just our opinion. We're just trying to make MariaDB better.

I believe that Massimo already fixed that by using network timeouts, so everyone should be happy at last. That intent to improve MariaDB is much appreciated , thanks for that.

The discussion about how to interpret standard is with Massimos fix less relevant, but thinking more about this and your arguments,and I think the "most correct" could the the following interpretation

1. Driver has no idea that timeout it is using and how to set one. Example : JDBC Type 2 driver, that relies on native library which has implicit settings, or something in config file or registry or somesuch.
getNetworkTimeout throws SQLFeatureNotImplemented
setNetworkTimeout does the same

2. "Read-only" Driver knows what timeout it is using, but this timeout cannot be set (MariaDB 1.1.7), or can only be set once, during connection creation, like in my prior example

getNetworkTimeout returns actual timeout
setNetworkTimeout throws Exception

3.Read-write timeout, like in the next version of MariaDB driver

getNetworkTimeout returns actual timeout
setNetworkTimeout sets timeout

This might be more elaborate than the simple "both work or both do not", but it looks right to me

Agreed. And it's great to see MariaDB implementing this feature. When used in combination with a (well designed) pool, it can greatly increase application recoverability from network interruptions.