Re: Single JDK14 compile model?

[David Van Couvering]

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 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. 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 :) David 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. Dan.