You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Patrick Mueller <pm...@yahoo.com> on 2004/10/01 14:54:17 UTC
Re: JSR169 support
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
pmuellr@yahoo.com