db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "RPost" <rp0...@pacbell.net>
Subject Re: Dynamically loaded DataValueFactory (JSR169)
Date Fri, 21 Jan 2005 18:18:32 GMT
Thanks for taking the time to make the extended comments explaining the

This sets a fine example for other developers to consider.

----- Original Message ----- 
From: "Daniel John Debrunner" <djd@debrunners.com>
To: "derby-dev" <derby-dev@db.apache.org>
Sent: Friday, January 21, 2005 9:53 AM
Subject: Dynamically loaded DataValueFactory (JSR169)

> 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.
> Version: GnuPG v1.2.5 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> iD8DBQFB8UGwIv0S4qsbfuQRAr5EAKChE8x+LgO7hOhHzhT4UmzNHbBvagCeMwnu
> g5j9AMqo7QIgd1KBuD3zwq0=
> =7eyk

View raw message