Recipe to Migrate Deprecated java.sql APIs

[tkvangorder]

More Risky Changes:
Notes about java.util.Date: The default constructor uses the JVM default time zone and starts at the beginning of the day. So the result may very based on where, when and what default time zone is. The java recommended replacement is Calendar, but there is a high cost to Calendar.newInstance. So, it's generally recommended to use either java.time or joda-time.
The solution for these are coupled to the deprecation of java.util.Date in #13.
Note: These APIs are related to deprecations of java.lang.Date in Java 1.1.

• java.sql.Date(int,int,int)
• int java.sql.Date.getHours()
• int java.sql.Date.getMinutes()
• int java.sql.Date.getSeconds()
• void java.sql.Date.setHours(int)
• void java.sql.Date.setMinutes(int)
• void java.sql.Date.setSeconds(int)
• java.sql.Time(int,int,int)
• int java.sql.Time.getYear()
• int java.sql.Time.getMonth()
• int java.sql.Time.getDay()
• int java.sql.Time.getDate()
• void java.sql.Time.setYear(int)
• void java.sql.Time.setMonth(int)
• void java.sql.Time.setDate(int)
• java.sql.Timestamp(int,int,int,int,int,int,int)

Deprecated in 1.2:

• void java.sql.DriverManager.setLogStream(java.io.PrintStream)
• java.io.PrintStream java.sql.DriverManager.getLogStream() // this is tricky, since the return type changes from a PrintStream to a PrintWriter.
• void java.sql.PreparedStatement.setUnicodeStream(int,java.io.InputStream,int) // tricky, since PreparedStatement is an interface. The changes would need to find all the implementations of the interface, make the method changes, and update all the references.
• java.io.InputStream java.sql.ResultSet.getUnicodeStream(int) // tricky, since it's an interface. Should wait until there is a known need for this migration.
• java.math.BigDecimal java.sql.ResultSet.getBigDecimal(java.lang.String,int) // tricky, since it's an interface. Should wait until there is a known need for this migration.
• java.math.BigDecimal java.sql.ResultSet.getBigDecimal(int,int) // tricky, since it's an interface. Should wait until there is a known need for this migration.
• java.math.BigDecimal java.sql.CallableStatement.getBigDecimal(int,int) // tricky, since it's an interface. Should wait until there is a known need for this migration.

Deprecated in Java 6:

• void javax.sql.rowset.BaseRowSet.setUnicodeStream(int,java.io.InputStream,int) -> setCharacterStream() // tricky, since it's an abstract class. Should wait until there is a known need for this migration.

[traceyyoshima]

I haven't looked at any of the checkboxes that aren't in the risky section yet. But what I did look at either introduces risk or requires more though than just a quick change. The changes are relatively straightforward, but the effects may cause harm without more thought.

I.E. CallableStatement.getBigDecimal(int, int) requires using .setScale() and .setScale requires setting a rounding mode. From the perspective of a recipe, we won't know what is happening behind the scenes in the database through stored procedures, and/or how potential changes in rounding may effect the code. Changes in rounding could have problematic results in companies focused on e-commerce if the call is buried in business logic that handles prices or taxes.

The deprecations of Date recommend the use of Calendar, but may introduce additional performance costs and cause unexpected issues. And/or may potentially cause odd edge cases related to timezones. I think the replacement of deprecated methods related to dates are doable, but I'm putting this issue aside for now to focus on quick wins.

Also, handling odd cases like getBigDecimal that may introduce risk needs discussion on how to communicate changes to a user. Do we leave a comment, marker, todo, do nothing, etc.

[traceyyoshima]

The rest of the deprecations pre-date Java 8 to 11, and aren't simple changes. I think we should wait to implement anything else that is listed until there is a known reason to tackle them.