db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Dynamically loaded DataValueFactory (JSR169)
Date Fri, 21 Jan 2005 17:53:53 GMT
Hash: SHA1

If you look at the attachments for Derby-97 you can see that
J2ME/CDC/Foundation/JSR169 support needs a dynamically loaded
DataValueFactory. I just checked in the initial support for that change.

The change was pretty simple because all of the code already referred to
the DataValueFactory methods through the interface DataValueFactory and
not the implementation DataValueFactoryImpl. The one class
(GenericLanguageConnectionFactory) that loaded DataValueFactory was
changed to request an implementation from the Monitor rather than
new'ing it directly. The DataValueFactoryImpl class is added to
module.properties with an jdk setting of 2, which means it supports JDK
1.3 or higher. Now the DataValueFactoryImpl  is only loaded indirectly
but doesn't need any special build code to add it to derby.jar as any
class in modules.properties is automatically added to the jar.

DataValueFactory module is loaded per-service (database) and not
per-system as it contains locale information which is specific to a
database. I think the handling of locales in the type system is not laid
out correctly but that's a separate cleanup.

Future changes in this area I will be doing are implementations of
DataValueFactory for JSR169 and J2SE5.0. Most likely the class heirachy
will change to be something like

abstract DataValueFactoryImpl (bulk of code for non DECIMAL types)
  -->> DataValueFactoryFoundation
  -->> DataValueFactoryJ2SE
         -->> DataValueFactoryJ2SE5

In the future there is also the potential to remove the interface
DataValueFactory and use the root of the above heirachy as the api. This
would be to reduce footprint. The issue with this change is there is
lots of code generation in the query tree nodes that calls methods in
DataValueFactory. If DataValueFactory changes from an interface to an
abstract class, then those have to be modified manually whereas regular
Java code is handled automatically by the compiler. The manual changes
are because the byte code to call methods through an interface is
different to calling methods through a class.

Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


View raw message