Derby JSR169 Design Notes

Initial Version 2004/12/15 – djd@debrunners.com

JDBC Implementation Classes

How the JDBC classes will implement the JDBC specifications and what changes are required.

DECIMAL Implementation

• DataValueFactory – Implementations of DataValueFactory will loaded by the Monitor and three implementations will exist:

• J2ME – Implementation for platforms without BigDecimal and BigInteger

• J2SE 1.3 & 1.4 – current implementation

• J2SE 5.0 – modified to take advantage of new BigDecimal code in J2SE 5.0, such as MathContext. Eventually this will map to hardware decimal arithmetic units, automatically.

• SQLDecimal – Code outside the DataValueFactory implementations will handle DECIMAL values through NumberDataValue interface only. There will be three SQLDecimal implementations to match the DataValueFactory implementations. The on-disk format for all three will be the same.

• J2ME – Implementation for platforms without BigDecimal and BigInteger, basic decimal arithemetic performed on the raw byte storage used for the on-disk storage format. This will reduce object allocation, currently to perform decimal arithemetic a BigInteger, a copy of the byte array (by BigInteger) and a BigDecimal must be created. This is also intended to support in the future OSGi ee.minimum execution platform (a sub-set of Foundation) which does not support BigDecimal, so no reliance on BigDecimal.

• J2SE 1.3 & 1.4 – current implementation

• J2SE 5.0 – modified to take advantage of new BigDecimal code in J2SE 5.0, such as MathContext.

• Decimal Arithmetic – Decimal arithmetic methods will be modified so they are defined and called with an extra parameter, that is intended to support the MathContext BigDecimal methods in J2SE 5.0. This parameter will represent the precision and/or scale of the result. More investigation is needed to see if this should be a DataTypeDescriptor, or simply an integer representing precision (which is what MathContext wraps).

Other Items

• Build order – build order will be changed so that all classes compiled with the base compile.classpath will be first. It is intended that this base classpath maps to the most restrictive platoform Derby will run on. This ordering is to ensure that classes built indirectly, through imports, and not reliant on J2SE classes by being built indirectly with a jdk13/jdk14 compile.classpath.

• Build – will most likely will require download of a Foundation environment, JSR 169 jars and J2SE 5.0 (1.5, tiger). Will see if this can be made optional in any way.

• J2ME/CDC/Foundation – Code compiled with the base classpath will only depend on classes in this profile. I believe the only class that is being used and not in the profile is java.math.BigDecimal.

• JDK_ID – A unique value will be used to indicate the JSR 169/Foundation platform. Need investigation to see how it relates to the current values.

• Ij – need investigation, need to isolate code that depends on Driver and DriverManager, like the XA support is handled. Ij does currently support connections through DataSource objects.

• sysinfo – See functional specification.

Commits

Changes wil be made in a number of incremental steps:

• Lazy approval will be assumed for checkins that are really just code shuffling, without major new features or new dependencies. E.g. Moving BigDecimal methods in the JDBC classes, re-ordering the build, adding extra info to sysinfo.

• Votes will be called for patches that add functionality or new dependencies to the build system. Eg. Adding DECIMAL arithemetic for Foundation, final JSR169 checkin, requirement for download of jdk1.5 for building Derby.