Thanks for taking the time to make the extended comments explaining the change.
This sets a fine example for other developers to consider. ----- Original Message ----- From: "Daniel John Debrunner" <[EMAIL PROTECTED]> To: "derby-dev" <[email protected]> Sent: Friday, January 21, 2005 9:53 AM Subject: Dynamically loaded DataValueFactory (JSR169) > -----BEGIN PGP SIGNED MESSAGE----- > 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. > > Dan. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFB8UGwIv0S4qsbfuQRAr5EAKChE8x+LgO7hOhHzhT4UmzNHbBvagCeMwnu > g5j9AMqo7QIgd1KBuD3zwq0= > =7eyk > -----END PGP SIGNATURE----- >
