Daniel John Debrunner wrote:
I'm going to look into completing JSR169 support for Derby. JSR169 support is a subset of JDBC 3.0 for J2ME/CDC/Foundation and OSGi ee.minimum platforms. J2ME/CDC/Foundation is the larger of the two main Java 2 Micro Edition environments. OSGi ee.minimum is a subset of J2ME/CDC/Foundation that does support the required classes for JSR169. The current code does have some of the initial work.
The changes are basically to support additional JVM settings like the support for JDK 1.3 and JDK 1.4 and in those environments, remove dependency on J2SE classes or methods that do not exist.
Some of the issues I know about are
- no java.math.BigDecimal - what to do about DECIMAL? - no java.sql.DriverManager (only DataSource api supported in JSR169) - no java.util.Observer & Observable - no java.text.MessageFormat - no java.util.Stack
You might be interested in taking a look at Eclipse SWT, as they have similiar issues supporting J2SE and J2ME. One of their tactics is to create a utility class which has two implementations, one for J2SE, one for J2ME. The methods in the class are the ones which require different implementations across the base class libraries. They actually build the jar with one of the two implementations.
I've done something similiar in the past, but made the decision at runtime instead of build time. The J2ME profiles tend to require particular System properties being set which you can query.
If the Derby source is compilable within Eclipse (haven't tried so I don't know; it's a question of how the source is structured), and you can get your hands on a jar matching the J2ME profile you are trying to build against, it's fairly simple for Eclipse to tell you where you're broken.
-- Patrick Mueller [EMAIL PROTECTED]
