Rather than a feature, it's Derby's support for that environment.
Today Derby supports from a single jar
J2SE 1.3 - requires JDK 1.3 to build J2SE 1.4 - requires JDK 1.4 to build J2SE 5.0 - runs in, doesn't yet take advantage of any J2SE 5.0 feature (except through reflection for BigDecimal.toPlainString)
Continuing that forward, I imagine in the future Derby will support from a single jar
J2ME/CDC/Foundation/JSR169 - requires foundation and JSR169 jars to build J2SE 1.3 - requires JDK 1.3 to build J2SE 1.4 - requires JDK 1.4 to build J2SE 5.0 - requires JDK 1.5 to build (takes advantage of J2SE 5.0 features)
Why the preference for a single jar(with lots of switching code inside) rather than different jars for different platform levels?
I would have thought for the ME platform the desire would be for as small a footprint as possible so eliminating all the non-169 code would be a benefit. At the other end, the 1.5 build could be optimized for that platform with features not in others (e.g. StringBuilder, atomics, ...) - plus no need to use reflection for toPlainString() :-)
-- Jeremy
