Daniel John Debrunner wrote:
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

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.
Hm, that might be useful, but what about cross-module functionality that we want all modules to make use of, such as exception chaining, assertions, logging (if we ever choose to do that), security, etc.  Or do we have to start talking about using AOP :)

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.