Drop NativeJdbcExtractor mechanism in favor of java.sql.Connection.unwrap() [SPR-14670]

[spring-projects-issues]

John Smith opened SPR-14670 and commented

Spring's NativeJdbcExtractor predates JDBC 4.0 and therefore Connection#unwrap. With JDBC 4 pools and drivers being reliably available now, there is no need to keep a separate mechanism around.

---

Reference URL: #1090

Issue Links:

• Remove native support for Hibernate 3.6 and 4.x [SPR-13827] #18400 Remove native support for Hibernate 3.6 and 4.x
• Drop outdated BeanFactoryLocator / beanRefContext.xml mechanism [SPR-15154] #19720 Drop outdated BeanFactoryLocator / beanRefContext.xml mechanism
• NPE in Spring-JDBC with Oracle and SimpleJdbcInsert [SPR-16495] #21038 NPE in Spring-JDBC with Oracle and SimpleJdbcInsert

Referenced from: commits 427fd9b, 07dd61e

[spring-projects-issues]

Juergen Hoeller commented

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.

[spring-projects-issues]

David Goblirsch commented

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.

[spring-projects-issues]

PavelStepanek commented

Hi - I have hit some issues as a result of this JIRA, can someone take a look here and help to clarify what is wrong? 

 

https://stackoverflow.com/questions/50295340/what-is-the-spring-5-jdbc-approach-when-nativejdbcextractor-is-needed

[nandeeshnaik]

Please pardon me for commenting on a closed thread.
I have an issue in Springboot migration from 1.5.9 to 2.3.1 related to JdbcTemplates's NativeJdbcExtractor.

I have linked the StackOverflow Question,
https://stackoverflow.com/questions/63055393/springboot-2-3-1-dynamically-update-jdbc-templates-schema-in-multi-tenant-envir?sem=2

It's basically related to dynamic update of JdbcTemplate's schema based on the REST call.

Is it even possible on Springboot2?
Should I get rid of JdbcTemplate? (Need lot of coding and testing effort)
Should I stop migrating?

Please help.