David Van Couvering wrote:
If the current situation (as I am beginning to understand) prevents us from taking advantage of numerous JDK 1.4 and 1.5 features, then I think this going to become more and more of a burden. As well as what Jeremy mentioned, there is exception chaining, and NIO support, and others I'm sure...
The current Derby architecture explictly allows modules to take advantage of features in various JDKs. SO there is no issue there. Derby can dynamically load different modules for different VM environments.
Sure but as we take more and more advantage of features in newer VMs then the number of different modules is going to grow and grow.
If the current situation also constrains our ability to add features because we're worried about overall size of the JAR for J2ME, this is a problem too.
Maybe an issue. The bulk of the code is currently in the SQL engine and compiler, which is required on J2ME. At the moment, splitting the code up to have a jar that just supports J2ME is not worth the effort. It may become an issue if analytics or other features are added, but I'll worry about that when it happens.
While I would like to see the current derby.jar get smaller, say 1Mb, I'm also half not convinced it's worth the effort. Having just got my wife an IPod mini with 4Gb storage, I was thinking given the really small physical size of such a device, what's the difference between 1Mb and 2Mb.
Drop it and see what still works (just don't tell the wife) - there is a big difference between rotating bits of plastic and flash. How much RAM does that iPod have? No more than 32MB I would guess, most of which will be buffer to let them spin down the drive to reduce shock risk and power drain.
To me the big issue is setting expectations with users - are they always going to be getting one jar or are they going to be able to choose between profiles based on JVM version, platform level, or SQL feature set.
I believe that some features are going to be big and complex (e.g. object type support, charsets/collations, geo/spatial, full-text indexing, analytics, ...) and very few users will want/need all of these. Ultimately we are going to want a mechanism that allows users to easily build the module configuration they want.
-- Jeremy
