Since we're raising the baseline to Java 8 for Spring 5 anyway, we tend to drop outdated mechanisms such as NativeJdbcExtractor completely. After all, on JDK 8+, there is no excuse for a pre-JDBC-4.0 driver or pool anymore, so Connection.unwrap is reliably available.
On 4.3.x - where we're still supporting WebSphere 7 and Oracle 9i JDBC drivers - it's hard to formally deprecate the mechanism. And in 5.0, keeping it around in deprecated form seems unnecessary. So we're simply going to drop it completely as of 5.0 M5.
This is just FYI. I understand that this issue is closed and that NativeJdbcExtractor is no longer required, but I just wanted to let you know that Connection.wrap() is much less efficient.
I created a pool using Apache Commons DBCP 2 for Oracle 12.1 using the oracle driver. Using Spring 4.3, I had an automated JUnit test suite with 5 tests that used OracleJdbc4NativeJdbcExtractor to extract OracleConnection, OracleStatement, and OraclePreparedStatement from the Connections returned from this pool, and from Statements and PreparedStatements built from those connections. The tests are very simple. For example, get a Connection from the pool, assert it is not an OracleConnection, apply nativeJdbcExtractor.getNativeConnection, assert the result is an OracleConnection. Similarly structured tests for Statement and PreparedStatement, and for the connections obtained from those.
(I am sorry but I cannot provide the actual test code.)
Running the tests on JDK 1.7 or JDK 1.8, for OracleJdbc4NativeJdbcExtractor, the 5 tests complete in 430 msec on average.
On Java 7, for java.sql.unwrap, the 5 tests complete in 2410 msec on average, almost 6x longer.
On Java 8, for java.sql.unwrap, the 5 tests complete in 1990 msec on average, almost 5x longer.
Looks like I might need to extract the NativeJdbcExtractor classes into a little utility library to keep around for some applications when I move them to Spring 5; your code is much more efficient than the JDK implementation. Not tested with 9 yet.